-
Notifications
You must be signed in to change notification settings - Fork 48
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
chore: add noble as separate github action #132
Conversation
Add a separate Github action for versions of Ubuntu in development which are prone to breaking. This way we can merge PR safely if the failure is unrelated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's a good idea. thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change seems okay, but why are we finding ways to ignore errors instead of fixing them? This is the error:
error: slice package "libssl3" missing from archive
That means people currently cannot use chisel in Noble. Shouldn't we address this as soon as we find it out, instead of finding ways to ignore the error?
@niemeyer The problem is that noble is not stable yet, meaning the slice definitions change frequently and break. This is something Cris has be struggling with lately because it requires a lot of changes to keep up with upstream. In my opinion, it is good to know that it is failing and we'll try to address it from the chisel-releases side but meanwhile, I think it should not impact releasing new versions of chisel the tool. It has to be treated similarly to a flaky test. |
Ironically, that's exactly my concern: flaky tests are irrelevant, because you learn to ignore them. Either we do care about what the tests are saying and pursue their correction timely when we see a breakage, or we disable the test because they are teaching us that broken tests are just fine. |
Proof of tests running https://github.com/canonical/chisel/actions/runs/8663377963/job/23757382499?pr=132#step:5:172:
|
The tests will help us identify the issues, and the split proposed in this PR makes sense because devel chisel-releases will tend to break more often than stable ones. Nonetheless, Chisel should still have a test for them. In this particular case, the fix needs to come in chisel-releases, and I've been in touch with the foundations team because this issue in particular is a tricky one. It is related to Y2038, in a way that Noble has now introduced a bunch of Since Chisel doesn't yet handle path conflicts nor architecture-specific essentials, our remediation (for now) will be to fully replace |
We have two options here:
Having a flaky test that we're fine to see red makes no sense. Who has been looking at the Spread logs on every PR change to see exactly which tests have failed again in Noble? The answer is certainly "nobody". We can trivially reenable the tests for Noble once you deem the release stable enough for that. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, Alberto.
Yep. I'm actually up for dropping these spread tests entirely, because now we have CI in the chisel-releases, which does a very similar job to what spread is doing here. The chisel-releases CI is flagging the same issues for 24.04 (and more, cause it's more than just So actually these tests become redundant. I'm ok if you want to drop them. |
Well but the ones here test the latest version in the PR before merging, as a sort of smoke test before any commit enters main. For an error to be caught by the CI in chisel-releases then it has to already be part of main. |
True. Let's talk about it offline. |
Remove noble from the CI because the tests break too often. Will add them back when the release is stable.