Hm. Looking at this some more I'm inclined to ask how common and supported a use case it is to use multiple repository types.

While this may in fact be possible, it seems like there hasn't been much effort elsewhere in the codebase to support it. For example, all repository types share the setting name :branch. Also the configure_scm method and all of SCMResolver seems to only support a single SCM.

And if support is shaky at best, I think it's reasonable to consider adding that support out of scope for this PR.

Oh, I didn't realize that was possible.

Hrm. I did consider making this accessible for all plugins though. The reason why I didn't just do that was twofold:

• using an array can easily become confusing (even if we limit it to scm plugins) because you basically have to run #detect on it every time you want to access something
• the obvious solution to that would be something like a hash, there is no straight-forward mechanism (that I know of) to get a plugin's name.

Maybe the better solution in this case would be to add an optional as argument so you can do, for instance install_plugin Capistrano::SCM::Git, as: :git, and that will define a git method that returns the plugin?

Let me know what you think.

This does make me realize a way around all this though (though it's less elegant). Something like:

set :git, Capistrano::SCM::Git.new
install_plugin fetch(:git)

Hmm, I wonder if this should be :scm_plugins (plural) as an array? I believe the installer allows someone to install multiple SCM plugins. Or in any case, it doesn't prevent this from happening. If there were to be multiple SCM plugins installed, then a singular scm_plugin is misleading and establishes the wrong API contract.

In which case I think @scm_plugins should be initialized to an empty array, and then your code could be changed slightly:

@scm_plugins << plugin if provides_scm?(plugin)

What do you think?

Accessible via scm_plugin method.

Summary

Provides a way to access the deployment's Capistrano::SCM::Plugin instance from within a deploy script. (via an scm_plugin method)

My use case for this was that I wanted to invoke git:check on my local machine, from which I trigger the deployment. As my local machine does not have a release role, it isn't possible to simply invoke the built-in rake task.

Short checklist

• [x] Did you run bundle exec rubocop -a to fix linter issues?
• [x] If relevant, did you create a test?
• [x] Did you confirm that the RSpec tests pass?

The latest MSYS2 package mingw-w64-ucrt-x86_64-libxslt-1.1.34-4 is now in the official repository and it fixes the date/time issue on UCRT64.

I dug into it a little more. Safari, Firefox, and Chrome all agree with the test. html5ever agrees with Gumbo and my reading of the spec. More details here. This could be a spec bug, so I filed an issue. It's more likely I'm just missing something subtle.

Everything from the "Functional Merger" section of this issue's description is done and on main.

What problem is this PR intended to solve?

Merge the remaining Nokogumbo tests into Nokogiri's test suite.

• [x] submodule @stevecheckoway's fork of html5lib-tests (see see https://github.com/rubys/nokogumbo/issues/170#issuecomment-797616327)
• [x] make sure these tests only run under CRuby
• [x] gumbo tests

Have you included adequate test coverage?

Tests are the entire substance of this PR.

Does this change affect the behavior of either the C or the Java implementations?

Notably, these additional tests should only run under CRuby.

One more instance: https://github.com/sparklemotion/nokogiri/pull/2273/checks?check_run_id=2863381608#step:7:40

What problem is this PR intended to solve?

Quite a bit of CI time is spent compiling our packaged dependencies (libxml2, libxslt, libiconv, zlib). For a given platform, we should be able to cache these libraries once compiled.

This PR does two things:

• move libgumbo out of /ports
• caches /ports for most jobs that were previously caching just /ports/archives (which only contains the tarballs)

I'll run CI twice on this branch and compare the timing to previous runs to make sure this is actually effective.

Pretty compelling before/after timings for the rake compile job:

What problem is this PR intended to solve?

Quite a bit of CI time is spent compiling our packaged dependencies (libxml2, libxslt, libiconv, zlib). For a given platform, we should be able to cache these libraries once compiled.

This PR does two things:

• move libgumbo out of /ports
• caches /ports for most jobs that were previously caching just /ports/archives (which only contains the tarballs)

I'll run CI twice on this branch and compare the timing to previous runs to make sure this is actually effective.

What problem is this PR intended to solve?

The 3.1.0.dev windows ruby installer uses UCRT, see #2268 for context. This gives Nokogiri and @larskanis a feedback loop.

Please describe the bug

A CI test run caught some memory errors in gumbo.

The build log is at https://github.com/sparklemotion/nokogiri/pull/2272/checks?check_run_id=2862967128

Here's the relevant snippet:

# Running tests with run options --seed 25442:

==489== Invalid read of size 8
==489==    at 0x8A170F4: parse_args_mark (gumbo.c:307)
==489==    by 0x490A58B: gc_mark_stacked_objects (gc.c:4737)
==489==    by 0x490A58B: gc_mark_stacked_objects_all (gc.c:4777)
==489==    by 0x490A58B: gc_marks_rest (gc.c:5653)
==489==    by 0x490AE9F: gc_marks (gc.c:5713)
==489==    by 0x490AE9F: gc_start (gc.c:6493)
==489==    by 0x490AE9F: gc_start (gc.c:6417)
==489==    by 0x490B5E2: garbage_collect (gc.c:6413)
==489==    by 0x490B5E2: gc_start_internal (gc.c:6722)
==489==    by 0x4A42198: vm_call_cfunc_with_frame (vm_insnhelper.c:1918)
==489==    by 0x4A42198: vm_call_cfunc (vm_insnhelper.c:1934)
==489==    by 0x4A4CEED: vm_exec_core (insns.def:915)
==489==    by 0x4A51FDC: vm_exec (vm.c:1778)
==489==    by 0x4A58F70: invoke_block (vm.c:979)
==489==    by 0x4A58F70: invoke_iseq_block_from_c (vm.c:1031)
==489==    by 0x4A58F70: invoke_block_from_c_bh (vm.c:1049)
==489==    by 0x4A58F70: vm_yield (vm.c:1094)
==489==    by 0x4A58F70: rb_yield_0 (vm_eval.c:970)
==489==    by 0x4A58F70: rb_yield_1 (vm_eval.c:976)
==489==    by 0x4A58F70: rb_yield (vm_eval.c:986)
==489==    by 0x487477B: rb_ary_each (array.c:1837)
==489==    by 0x4A42198: vm_call_cfunc_with_frame (vm_insnhelper.c:1918)
==489==    by 0x4A42198: vm_call_cfunc (vm_insnhelper.c:1934)
==489==    by 0x4A4D962: vm_exec_core (insns.def:850)
==489==    by 0x4A51FDC: vm_exec (vm.c:1778)
==489==    by 0x4A58F70: invoke_block (vm.c:979)
==489==    by 0x4A58F70: invoke_iseq_block_from_c (vm.c:1031)
==489==    by 0x4A58F70: invoke_block_from_c_bh (vm.c:1049)
==489==    by 0x4A58F70: vm_yield (vm.c:1094)
==489==    by 0x4A58F70: rb_yield_0 (vm_eval.c:970)
==489==    by 0x4A58F70: rb_yield_1 (vm_eval.c:976)
==489==    by 0x4A58F70: rb_yield (vm_eval.c:986)
==489==    by 0x487477B: rb_ary_each (array.c:1837)
==489==    by 0x4A42198: vm_call_cfunc_with_frame (vm_insnhelper.c:1918)
==489==    by 0x4A42198: vm_call_cfunc (vm_insnhelper.c:1934)
==489==    by 0x4A4D962: vm_exec_core (insns.def:850)
==489==    by 0x4A51FDC: vm_exec (vm.c:1778)
==489==    by 0x4A584C4: invoke_block (vm.c:979)
==489==    by 0x4A584C4: invoke_iseq_block_from_c (vm.c:1031)
==489==    by 0x4A584C4: invoke_block_from_c_bh (vm.c:1049)
==489==    by 0x4A584C4: vm_yield_force_blockarg (vm.c:1110)
==489==    by 0x4A584C4: rb_yield_force_blockarg (vm_eval.c:1035)
==489==    by 0x4878FAB: rb_ary_collect (array.c:2758)
==489==    by 0x4A42198: vm_call_cfunc_with_frame (vm_insnhelper.c:1918)
==489==    by 0x4A42198: vm_call_cfunc (vm_insnhelper.c:1934)
==489==    by 0x4A53E8B: vm_call_method_each_type.part.135 (vm_insnhelper.c:2232)
==489==    by 0x4A5450A: vm_call_method_each_type (vm_insnhelper.c:2380)
==489==    by 0x4A5450A: vm_call_method (vm_insnhelper.c:2384)
==489==    by 0x4A5450A: vm_call_method (vm_insnhelper.c:2351)
==489==    by 0x4A4D962: vm_exec_core (insns.def:850)
==489==    by 0x4A51FDC: vm_exec (vm.c:1778)
==489==    by 0x4A52BAA: invoke_block (vm.c:979)
==489==    by 0x4A52BAA: invoke_iseq_block_from_c (vm.c:1031)
==489==    by 0x4A53889: invoke_block_from_c_proc (vm.c:1124)
==489==    by 0x4A53889: vm_invoke_proc (vm.c:1149)
==489==    by 0x4984B18: rb_proc_call (proc.c:887)
==489==    by 0x48F401C: exec_end_procs_chain (eval_jump.c:108)
==489==    by 0x48F401C: rb_exec_end_proc (eval_jump.c:125)
==489==    by 0x48F4171: ruby_finalize_0 (eval.c:124)
==489==    by 0x48F4497: ruby_cleanup (eval.c:182)
==489==    by 0x48F47C4: ruby_run_node (eval.c:303)
==489==    by 0x1090EA: main (main.c:42)
==489==  Address 0x1ffeffcce8 is on thread 1's stack
==489==  312 bytes below stack pointer
==489== 
{
   <insert_a_suppression_name_here>
   Memcheck:Addr8
   fun:parse_args_mark
   fun:gc_mark_stacked_objects
   fun:gc_mark_stacked_objects_all
   fun:gc_marks_rest
   fun:gc_marks
   fun:gc_start
   fun:gc_start
   fun:garbage_collect
   fun:gc_start_internal
   fun:vm_call_cfunc_with_frame
   fun:vm_call_cfunc
   fun:vm_exec_core
   fun:vm_exec
   fun:invoke_block
   fun:invoke_iseq_block_from_c
   fun:invoke_block_from_c_bh
   fun:vm_yield
   fun:rb_yield_0
   fun:rb_yield_1
   fun:rb_yield
   fun:rb_ary_each
   fun:vm_call_cfunc_with_frame
   fun:vm_call_cfunc
   fun:vm_exec_core
   fun:vm_exec
   fun:invoke_block
   fun:invoke_iseq_block_from_c
   fun:invoke_block_from_c_bh
   fun:vm_yield
   fun:rb_yield_0
   fun:rb_yield_1
   fun:rb_yield
   fun:rb_ary_each
   fun:vm_call_cfunc_with_frame
   fun:vm_call_cfunc
   fun:vm_exec_core
   fun:vm_exec
   fun:invoke_block
   fun:invoke_iseq_block_from_c
   fun:invoke_block_from_c_bh
   fun:vm_yield_force_blockarg
   fun:rb_yield_force_blockarg
   fun:rb_ary_collect
   fun:vm_call_cfunc_with_frame
   fun:vm_call_cfunc
   fun:vm_call_method_each_type.part.135
   fun:vm_call_method_each_type
   fun:vm_call_method
   fun:vm_call_method
   fun:vm_exec_core
   fun:vm_exec
   fun:invoke_block
   fun:invoke_iseq_block_from_c
   fun:invoke_block_from_c_proc
   fun:vm_invoke_proc
   fun:rb_proc_call
   fun:exec_end_procs_chain
   fun:rb_exec_end_proc
   fun:ruby_finalize_0
   fun:ruby_cleanup
   fun:ruby_run_node
   fun:main
}
==489== Invalid read of size 8
==489==    at 0x8A170FD: parse_args_mark (gumbo.c:308)
==489==    by 0x490A58B: gc_mark_stacked_objects (gc.c:4737)
==489==    by 0x490A58B: gc_mark_stacked_objects_all (gc.c:4777)
==489==    by 0x490A58B: gc_marks_rest (gc.c:5653)
==489==    by 0x490AE9F: gc_marks (gc.c:5713)
==489==    by 0x490AE9F: gc_start (gc.c:6493)
==489==    by 0x490AE9F: gc_start (gc.c:6417)
==489==    by 0x490B5E2: garbage_collect (gc.c:6413)
==489==    by 0x490B5E2: gc_start_internal (gc.c:6722)
==489==    by 0x4A42198: vm_call_cfunc_with_frame (vm_insnhelper.c:1918)
==489==    by 0x4A42198: vm_call_cfunc (vm_insnhelper.c:1934)
==489==    by 0x4A4CEED: vm_exec_core (insns.def:915)
==489==    by 0x4A51FDC: vm_exec (vm.c:1778)
==489==    by 0x4A58F70: invoke_block (vm.c:979)
==489==    by 0x4A58F70: invoke_iseq_block_from_c (vm.c:1031)
==489==    by 0x4A58F70: invoke_block_from_c_bh (vm.c:1049)
==489==    by 0x4A58F70: vm_yield (vm.c:1094)
==489==    by 0x4A58F70: rb_yield_0 (vm_eval.c:970)
==489==    by 0x4A58F70: rb_yield_1 (vm_eval.c:976)
==489==    by 0x4A58F70: rb_yield (vm_eval.c:986)
==489==    by 0x487477B: rb_ary_each (array.c:1837)
==489==    by 0x4A42198: vm_call_cfunc_with_frame (vm_insnhelper.c:1918)
==489==    by 0x4A42198: vm_call_cfunc (vm_insnhelper.c:1934)
==489==    by 0x4A4D962: vm_exec_core (insns.def:850)
==489==    by 0x4A51FDC: vm_exec (vm.c:1778)
==489==    by 0x4A58F70: invoke_block (vm.c:979)
==489==    by 0x4A58F70: invoke_iseq_block_from_c (vm.c:1031)
==489==    by 0x4A58F70: invoke_block_from_c_bh (vm.c:1049)
==489==    by 0x4A58F70: vm_yield (vm.c:1094)
==489==    by 0x4A58F70: rb_yield_0 (vm_eval.c:970)
==489==    by 0x4A58F70: rb_yield_1 (vm_eval.c:976)
==489==    by 0x4A58F70: rb_yield (vm_eval.c:986)
==489==    by 0x487477B: rb_ary_each (array.c:1837)
==489==    by 0x4A42198: vm_call_cfunc_with_frame (vm_insnhelper.c:1918)
==489==    by 0x4A42198: vm_call_cfunc (vm_insnhelper.c:1934)
==489==    by 0x4A4D962: vm_exec_core (insns.def:850)
==489==    by 0x4A51FDC: vm_exec (vm.c:1778)
==489==    by 0x4A584C4: invoke_block (vm.c:979)
==489==    by 0x4A584C4: invoke_iseq_block_from_c (vm.c:1031)
==489==    by 0x4A584C4: invoke_block_from_c_bh (vm.c:1049)
==489==    by 0x4A584C4: vm_yield_force_blockarg (vm.c:1110)
==489==    by 0x4A584C4: rb_yield_force_blockarg (vm_eval.c:1035)
==489==    by 0x4878FAB: rb_ary_collect (array.c:2758)
==489==    by 0x4A42198: vm_call_cfunc_with_frame (vm_insnhelper.c:1918)
==489==    by 0x4A42198: vm_call_cfunc (vm_insnhelper.c:1934)
==489==    by 0x4A53E8B: vm_call_method_each_type.part.135 (vm_insnhelper.c:2232)
==489==    by 0x4A5450A: vm_call_method_each_type (vm_insnhelper.c:2380)
==489==    by 0x4A5450A: vm_call_method (vm_insnhelper.c:2384)
==489==    by 0x4A5450A: vm_call_method (vm_insnhelper.c:2351)
==489==    by 0x4A4D962: vm_exec_core (insns.def:850)
==489==    by 0x4A51FDC: vm_exec (vm.c:1778)
==489==    by 0x4A52BAA: invoke_block (vm.c:979)
==489==    by 0x4A52BAA: invoke_iseq_block_from_c (vm.c:1031)
==489==    by 0x4A53889: invoke_block_from_c_proc (vm.c:1124)
==489==    by 0x4A53889: vm_invoke_proc (vm.c:1149)
==489==    by 0x4984B18: rb_proc_call (proc.c:887)
==489==    by 0x48F401C: exec_end_procs_chain (eval_jump.c:108)
==489==    by 0x48F401C: rb_exec_end_proc (eval_jump.c:125)
==489==    by 0x48F4171: ruby_finalize_0 (eval.c:124)
==489==    by 0x48F4497: ruby_cleanup (eval.c:182)
==489==    by 0x48F47C4: ruby_run_node (eval.c:303)
==489==    by 0x1090EA: main (main.c:42)
==489==  Address 0x1ffeffccf0 is on thread 1's stack
==489==  304 bytes below stack pointer
==489== 
{
   <insert_a_suppression_name_here>
   Memcheck:Addr8
   fun:parse_args_mark
   fun:gc_mark_stacked_objects
   fun:gc_mark_stacked_objects_all
   fun:gc_marks_rest
   fun:gc_marks
   fun:gc_start
   fun:gc_start
   fun:garbage_collect
   fun:gc_start_internal
   fun:vm_call_cfunc_with_frame
   fun:vm_call_cfunc
   fun:vm_exec_core
   fun:vm_exec
   fun:invoke_block
   fun:invoke_iseq_block_from_c
   fun:invoke_block_from_c_bh
   fun:vm_yield
   fun:rb_yield_0
   fun:rb_yield_1
   fun:rb_yield
   fun:rb_ary_each
   fun:vm_call_cfunc_with_frame
   fun:vm_call_cfunc
   fun:vm_exec_core
   fun:vm_exec
   fun:invoke_block
   fun:invoke_iseq_block_from_c
   fun:invoke_block_from_c_bh
   fun:vm_yield
   fun:rb_yield_0
   fun:rb_yield_1
   fun:rb_yield
   fun:rb_ary_each
   fun:vm_call_cfunc_with_frame
   fun:vm_call_cfunc
   fun:vm_exec_core
   fun:vm_exec
   fun:invoke_block
   fun:invoke_iseq_block_from_c
   fun:invoke_block_from_c_bh
   fun:vm_yield_force_blockarg
   fun:rb_yield_force_blockarg
   fun:rb_ary_collect
   fun:vm_call_cfunc_with_frame
   fun:vm_call_cfunc
   fun:vm_call_method_each_type.part.135
   fun:vm_call_method_each_type
   fun:vm_call_method
   fun:vm_call_method
   fun:vm_exec_core
   fun:vm_exec
   fun:invoke_block
   fun:invoke_iseq_block_from_c
   fun:invoke_block_from_c_proc
   fun:vm_invoke_proc
   fun:rb_proc_call
   fun:exec_end_procs_chain
   fun:rb_exec_end_proc
   fun:ruby_finalize_0
   fun:ruby_cleanup
   fun:ruby_run_node
   fun:main
}

After giving it some thought, this isn't something I'm willing to spend time to fix. If you want to spend some time to describe the behavior you think Nokogiri should have in this case, and write a PR for it, I'd be happy to review.

Please describe the bug

The lang attribute is duplicated after serialization/deserialization if remove_namespaces! is used.

<html xmlns="http://www.w3.org/1999/xhtml" lang="x" lang="x" lang="x" xml:lang="x"></html>

Help us reproduce what you're seeing

Here is a reproduction script:

#!/usr/bin/env ruby

require "nokogiri"

def from_xml(str)
	parse_options = Nokogiri::XML::ParseOptions::DEFAULT_XML
	doc = Nokogiri::XML::Document.parse(str, nil, nil, parse_options)
	doc.remove_namespaces! # <<< the bug disappears if this line is commented out
	return doc
end

doc = from_xml("<html lang='x'/>")
doc_str = doc.to_xhtml; puts doc_str

doc2 = from_xml(doc_str)
doc2_str = doc2.to_xhtml; puts doc2_str

doc3 = from_xml(doc2_str)
doc3_str = doc3.to_xhtml; puts doc3_str

raise "Different serialization" unless doc_str == doc2_str

Expected behavior / Actual behavior

One would expect the document to not change after a serialization/deserialization cycle.

The reproduction script should output the following lines:

<html xmlns="http://www.w3.org/1999/xhtml" lang="x" xml:lang="x"></html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="x" xml:lang="x"></html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="x" xml:lang="x"></html>

Instead it produces this output:

<html xmlns="http://www.w3.org/1999/xhtml" lang="x" xml:lang="x"></html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="x" lang="x" xml:lang="x"></html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="x" lang="x" lang="x" xml:lang="x"></html>
Traceback (most recent call last):
./lang-test.rb:24:in `<main>': Different serialization (RuntimeError)

Environment

$ nokogiri -v
# Nokogiri (1.11.7)
    ---
    warnings: []
    nokogiri:
      version: 1.11.7
      cppflags:
      - "-I/[RBENV]/versions/2.6.2/lib/ruby/gems/2.6.0/gems/nokogiri-1.11.7-x86_64-linux/ext/nokogiri"
      - "-I/[RBENV]/versions/2.6.2/lib/ruby/gems/2.6.0/gems/nokogiri-1.11.7-x86_64-linux/ext/nokogiri/include"
      - "-I/[RBENV]/versions/2.6.2/lib/ruby/gems/2.6.0/gems/nokogiri-1.11.7-x86_64-linux/ext/nokogiri/include/libxml2"
      ldflags: []
    ruby:
      version: 2.6.2
      platform: x86_64-linux
      gem_platform: x86_64-linux
      description: ruby 2.6.2p47 (2019-03-13 revision 67232) [x86_64-linux]
      engine: ruby
    libxml:
      source: packaged
      precompiled: true
      patches:
      - 0001-Remove-script-macro-support.patch
      - 0002-Update-entities-to-remove-handling-of-ssi.patch
      - 0003-libxml2.la-is-in-top_builddir.patch
      - 0004-use-glibc-strlen.patch
      - 0005-avoid-isnan-isinf.patch
      - 0006-update-automake-files-for-arm64.patch
      - 0007-Fix-XPath-recursion-limit.patch
      libxml2_path: "/[RBENV]/versions/2.6.2/lib/ruby/gems/2.6.0/gems/nokogiri-1.11.7-x86_64-linux/ext/nokogiri"
      memory_management: ruby
      iconv_enabled: true
      compiled: 2.9.12
      loaded: 2.9.12
    libxslt:
      source: packaged
      precompiled: true
      patches:
      - 0001-update-automake-files-for-arm64.patch
      - 0002-Fix-xml2-config-check-in-configure-script.patch
      compiled: 1.1.34
      loaded: 1.1.34
    other_libraries:
      zlib: 1.2.11