-
Notifications
You must be signed in to change notification settings - Fork 157
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
write validation to let us know when packages in next-devel
are older than testing-devel
#1671
Comments
For example, as of today the output includes:
So I'll go through and find updates for each of these and then add them as overrides to
And we can find the update URL from that:
Now we just need to run it through
NOTE: you can pass more than one bodhi URL to |
If you can reduce that process entirely to code, it would make sense to add a periodic GitHub Actions workflow that submits PRs, based on add-override.yml. |
Exactly. This was the start of that. I wanted to get my steps down and then someone (or maybe me) can pick it up and push it forward. This was step 1. |
This might not even be a bot, it could be a check added to the pipeline which warns if an older package is detected. This could even be a test that is in the config repo. |
next-devel
are older than testing-devel
next-devel
are older than testing-devel
I'm attempting to write some automation for this but I've ran into a couple of scenarios that need to be addressed:
What other scenarios could be a challenge? What I've been doing right now is a mixture of automation and HITL. I'm running a script that performs the steps outlined by Dusty to produce a list of packages that are showing as downgraded along with their bodhi updates for F(n+1). I then have to manually update the manifest lock files or call |
Nice. Thanks for working on this. Yes if we could update overrides.py to handle packages that are specific to particular architectures that would cause us much less pain not only for this but normal overrides when we do them. Warnings sound good to me when there are cases that need extra attention. One other case we migth want to flag is when the update we are fast-tracking isn't currently in the |
The idea here is that we never want someone upgrading to have package downgrades (unless we explicitly decided to do that). In the period of time where
next
is on the N+1 Fedora if packages in that stream sort older (NVR) than what is in thetesting
streams things are setting up such that packages will "downgrade" at some point as part of an update. This "downgrades" are common in the lead up to the release of the next Fedora major version because there are periods of "freeze" for N+1, but N continues rolling.One way to get in front of this is to make sure packages in
next-devel
always NVR sort newer than packages intesting-devel
.Let's write a bot that will let us know when this happens.
Today I use the following steps to determine which packages are downgraded:
The text was updated successfully, but these errors were encountered: