Skip to content

Use parse_spec_no_baseline with :/ for all 2.47.* on CI #1774

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

Merged
merged 1 commit into from
Jan 18, 2025

Conversation

EliahKagan
Copy link
Member

@EliahKagan EliahKagan commented Jan 17, 2025

The bug in Git that causes #1622 has been fixed since 2.48.0 and does not affect any versions prior to 2.47, but the fix is not backported to subsequent 2.47.* point releases. In particular, 2.47.2 has been released, with backported security fixes, but it does not have a backported fix for this non-security bug.

This builds on #1635 and #1719 by updating the range of Git versions where we skip the affected baseline checks on CI (for platforms this affects on our CI) from (2, 47, 0)..(2, 47, 2) to (2, 47, 0)..(2, 48, 0), i.e., with the exclusive upper bound changed from 2.47.2 to the correct value of 2.48.0. This also revises the comments accordingly.

For further details, see #1622 (comment). This change is item (1) there.

The bug in Git that causes GitoxideLabs#1622 has been fixed since 2.48.0 and
does not affect any versions prior to 2.47, but the fix is not
backported to subsequent 2.47.* point releases. In particular,
2.47.2 has been released, with backported security fixes, but it
does not have backported fixes for this non-security bug.

This builds on GitoxideLabs#1635 and GitoxideLabs#1719 by updating the range of Git
versions where we skip the affected baseline checks on CI (for
platforms this affects on our CI) from `(2, 47, 0)..(2, 47, 2)` to
`(2, 47, 0)..(2, 48, 0)`, i.e., with the exclusive upper bound
changed from 2.47.2 to the correct value of 2.48.0. This also
revises the comments accordingly.

For further details, see:
GitoxideLabs#1622 (comment)
(This change is item (1) there.)
@EliahKagan EliahKagan changed the title Use parse_spec_no_baseline with :/ for all 2.47.* on CI Use parse_spec_no_baseline with :/ for all 2.47.* on CI Jan 17, 2025
@Byron
Copy link
Member

Byron commented Jan 18, 2025

Thanks a lot for taking such good care of this and following up. The sequence of actions in #1622 (comment) seems reasonable as well.

@Byron Byron merged commit 90e08f1 into GitoxideLabs:main Jan 18, 2025
19 checks passed
@EliahKagan EliahKagan deleted the complex-graph-no-baseline-next branch January 18, 2025 18:52
EliahKagan added a commit to EliahKagan/gitoxide that referenced this pull request May 5, 2025
For GitoxideLabs#1622, baseline comparisons in `find_youngest_matching_commit`
where Git 2.47.* produces incorrect results were conditionally
suppressed in the `regex_matches` test case in GitoxideLabs#1635. That was
refined in GitoxideLabs#1719, and further refined in GitoxideLabs#1774.

This builds on those, making substantial changes, in view of how:

- We expect that CI have a very recent Git. The runners have been
  past 2.47.* for some time, and now have 2.49.*. Therefore it is
  no longer desirable to suppress the baseline comparison on CI.

- GitoxideLabs#1774 only examined the `regex_matches` test case. That test runs
  when the `revparse-regex` feature, which is a default `gix`
  feature, is enabled.

  But when `revparse-regex` is not enabled, the
  `contained_string_matches` test case runs instead. This test
  suffers the same baseline comparison failures with the same Git
  versions, due to assertions analogous to those that were adjusted
  to let `regex_matches` proceed and pass.

  This can be verified by running

      PATH="$HOME/git-2.47.2/bin:$PATH" GIX_TEST_IGNORE_ARCHIVES=1 \
          cargo nextest run -p gix \
          revision::spec::from_bytes::regex::find_youngest_matching_commit \
          --no-fail-fast --no-default-features \
          --features max-performance-safe,comfort,basic

  where the `PATH` environment variable is set differently if the
  `git` command provided in a Git 2.47.* installation is elsewhere
  than `~/git-2.47.2/bin`. Output from such a run can be seen in:
  https://gist.github.com/EliahKagan/bd8525d048350fc80a7666d8819089db

  Therefore, if a conditional suppression of the baseline
  comparison is to be preserved in `regex_matches`, then an
  analogous suppression under the same conditions should be added
  to `contained_string_matches`.

- Although most operating systems that package Git seem not to have
  2.47.* as their latest available downstream version in any
  release, it seems a few do. In particular, Alpine Linux v3.21 has
  git 2.47.2-r0, as shown at:
  https://pkgs.alpinelinux.org/packages?name=git&branch=v3.21&repo=&arch=x86_64&origin=&flagged=&maintainer=

  Therefore, if it is desirable to work with as wide a range as
  possible of (currently supported) operating system releases as
  development environments, there may be a benefit to conditionally
  suppressing the baseline tests when Git 2.47.* is used *locally*.

- However, doing this locally carries two downsides. First, the
  test code (even if refactored to decrease duplication) will be
  more complicated than if this is not done.

  Second, such an environment will still not be suitable for all
  development tasks, because generating the relevant test fixtures
  on it will contain incorrect baselines and therefore must not be
  committed.

  If they were to be committed by accident, then the problem would
  most likely be caught, because the tests would fail on CI, in
  other environments, and even in the same environment when run
  without `GIX_TEST_IGNORE_ARCHIVES` (in the absence of which the
  baseline comparisons are not suppressed).

  So this is not likely to have severely harmful effects. But it
  could be frustrating, because suppressing the baseline
  comparisons locally hides the usual evidence that the generated
  archives might not be suitable for committing.

This commit keeps the baseline comparison in `regex_matches` but
inverts its CI check so the suppression is only done locally rather
than only on CI, adds the same (modified) suppression to the
analogous `contained_string_matches` test case, and updates
comments accordingly. We may or may not keep this approach.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants