Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ci: manage XMLResolver.org XML Resolver version #1746

Merged
merged 4 commits into from
Jun 28, 2023

Conversation

AirQuick
Copy link
Member

While XML resolver in general plays a critical role, it can be buggy.
Now, Saxon, XML Calabash and Oxygen come bundled with different versions of XMLResolver.org XML Resolver. So, when a problem happens, it's getting hard to spot where the problem is.

This pull request deletes the bundled versions and install a specific version before running the tests.
With this change, we will be able to

  • Test with the latest version as soon as it's released.
  • Skip buggy versions.

@AirQuick AirQuick added the test label Jun 13, 2023
@AirQuick AirQuick added this to the v2.3 milestone Jun 13, 2023
Copy link
Member

@galtm galtm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this change is well motivated and well executed, including helpful comments. It might even enable XSpec to detect and report a relevant XML Resolver bug sooner.

My only concern about overriding the bundling is that it could mask problems that end users experience when using the bundled version of the XMLResolver.org XML Resolver application. I think we can mitigate that risk through our own awareness, though. If a user reports a problem that isn't reproducible via the XSpec test suite, we should check whether the XML Resolver version is a difference between the test suite's environment and the user's environment.

One question: Are you thinking that the XSpec testing should routinely update the XMLResolver.org XML Resolver version, even if XML Calabash and Saxon have not adopted the new version yet and updating is not needed as a bug workaround? You wrote "able to Test with the latest version as soon as it's released" and my question is whether you see that as more of a theoretical capability or an operating standard.

AirQuick and others added 3 commits June 17, 2023 02:45
…resolverorg-xmlresolver

# Conflicts:
#	test/run-bats.cmd
#	test/run-bats.sh
#	test/win-bats/collection.xml
…resolverorg-xmlresolver

# Conflicts:
#	test/xspec.bats
@galtm galtm enabled auto-merge (squash) June 28, 2023 11:07
@galtm galtm merged commit bc645b2 into xspec:master Jun 28, 2023
39 checks passed
@AirQuick AirQuick deleted the test_separate-xmlresolverorg-xmlresolver branch July 5, 2023 04:13
@AirQuick
Copy link
Member Author

AirQuick commented Jul 5, 2023

Are you thinking that the XSpec testing should routinely update the XMLResolver.org XML Resolver version, even if XML Calabash and Saxon have not adopted the new version yet and updating is not needed as a bug workaround?

Yes, I think we should always keep the XMLResolver.org XML Resolver base version updated. That would prevent a buggy version from being shipped with Saxon.

@galtm
Copy link
Member

galtm commented Jul 5, 2023

Yes, I think we should always keep the XMLResolver.org XML Resolver base version updated.

Great, thanks for confirming. I added mention about the XML resolvers to Update Third-Party Dependencies. Not sure if you have seen that page, but I created it to keep some basic facts/references about various dependencies in one place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants