Skip to content

CI: remove invalidations checks #97

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

Closed
wants to merge 1 commit into from
Closed

Conversation

fingolfin
Copy link
Member

These don't work well in practice; lots of fluctuations caused by
changes in Julia and dependencies. The README for
julia-actions/julia-invalidations states:

WARNING: this action may place blame in the wrong place. In most
cases invalidation is the "fault" of the victim of invalidation,
not the perpetrator

These don't work well in practice; lots of fluctuations caused by
changes in Julia and dependencies. The README for
`julia-actions/julia-invalidations` states:

> WARNING: this action may place blame in the wrong place. In most
> cases invalidation is the "fault" of the victim of invalidation,
> not the perpetrator
@LilithHafner
Copy link
Member

IIUC, this check only fails if the PR branch has more invalidations than the head branch, so fluctuations due to changes in Julia and deps should not cause the check to fail.

@fingolfin
Copy link
Member Author

Yes that's the theory, but in reality it was a constant source of pain. We tried this on AbstractAlgebra, Nemo, Oscar and a bunch of other repositories. In the end it constantly failed, and led to zero prevented invalidations.

Among the issues (some might be fixable) with this action:

  • this compares against the default branch (master / main), not the current merge commit for the PR. Meaning that if between the step which measure master and the step which measures the branch someone merges a PR, you end up comparing apple and oranges (granted this affects busy repositories more than others)
  • IIRC dependencies are resolved twice... you'd think it is rare but more than once did this result in a dependency being updated between the first and second run
  • in any case when the two branches have different dependencies that of course also affects invalidations

But perhaps if a project starts out at (close to) zero invalidations it is more useful... shrug

@LilithHafner
Copy link
Member

In my time maintaining SortingAlgorithms.jl I have yet to experience the pain you describe. Every spurious failure has been due to julia-actions/julia-invalidations#16. I'd like to wait until we have relevant spurious failures before removing the check here.

@fingolfin
Copy link
Member Author

Fair enough, your choice

@fingolfin fingolfin closed this Mar 19, 2025
@fingolfin fingolfin deleted the mh/invalidations branch March 19, 2025 13:35
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