Regenerate CI workflows with xmsconan 2.18.0 - #130
Merged
Conversation
CI has to generate the recipe with the same xmsconan the manual VS2019 track
uses, or the two remotes end up carrying different recipe revisions for the
same version.
XmsConan2File.export() copies xms_conan2_file.py into the export folder, so its
contents feed the recipe revision hash. 2.18.0 changes that file by 192 lines
(the msvc 192 fork: _is_vs2019, vs2019_requirements, vs2019_dependency_
overrides). A 7.0.x built by CI on the 2.16.0 pin and the same 7.0.x built
locally for VS2019 on 2.18.0 would therefore export different recipes and
resolve to different rrevs -- aquaveo-stable and aquaveo-vs2019 silently out of
step on a version that reads as one release.
Nothing else in the generated output moves. Diffed against a real 2.16.0
install: conanfile.py, CMakeLists.txt and pytest.ini are byte-identical
(conanfile.py gains a vs2019_dependency_overrides attribute only when
build.toml declares that table, and this one does not). build.py gains an exit
1 when builder.upload() reports errors instead of failing silently, and is not
exported. On any toolchain that is not msvc 192 the dependency graph is
unchanged: 2.18.0 refactored the inline self.requires("boost/1.86.0") /
self.requires("zlib/1.3.1") calls into an iteration over default_requirements
holding those same references in the same order.
The pins also stop being pins. 2.17.0 floated generated CI onto
>= with --upgrade, so this is the last regeneration commit this repo needs --
a later xmsconan reaches CI on its next run. The flake job picks up --upgrade
here, which it lacked under the == pin.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps generated CI onto xmsconan 2.18.0 (The VS2019 Bridge Release). Five lines, all pins.
Why this is required, not housekeeping
XmsConan2File.export()copiesxms_conan2_file.pyinto the export folder, so its contents feed the recipe revision hash. 2.18.0 changes that file by 192 lines — the msvc 192 fork (_is_vs2019,vs2019_requirements,vs2019_dependency_overrides).That means a
7.0.xbuilt by CI on the2.16.0pin and the same7.0.xbuilt locally for VS2019 on 2.18.0 export different recipes and resolve to different rrevs.aquaveo-stableandaquaveo-vs2019would be silently out of step on a version that reads as one release — precisely the failure the VS2019 bridge exists to avoid. Both sides have to generate from the same xmsconan.Blast radius on the VS2022 side: none
Diffed the generated output against a real
xmsconan==2.16.0install (not the editable one):conanfile.pyCMakeLists.txtpytest.inibuild.pyexit 1whenbuilder.upload()reports errors, instead of failing silently. Not exported.xms_conan2_file.pyconanfile.pygains avs2019_dependency_overridesattribute only whenbuild.tomldeclares that table; this repo doesn't, so it regenerates byte-identical.On any toolchain that is not msvc 192 the dependency graph is unchanged. 2.18.0 refactored the inline
self.requires("boost/1.86.0")/self.requires("zlib/1.3.1")calls into an iteration overdefault_requirements, which holds those same two references in the same order.This should be the last regeneration commit
2.17.0 floated generated CI from
==onto>=with--upgrade, so a future xmsconan reaches CI on its next run rather than waiting on a regenerate-and-commit pass. The flake job picks up--upgradehere, which it lacked under the==pin.Note
Coverage.yamlwas already floating (>=2.16.0); only its floor moves.🤖 Generated with Claude Code