-
Notifications
You must be signed in to change notification settings - Fork 524
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
Archive old migrations #1540
Archive old migrations #1540
Conversation
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.
Awesome.
We should do this in every future PR that we bump the version in Release.toml
.
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 GitHub UI truncates the file paths. Did you push these down to something like sources/api/migration/migrations/archived
?
Exactly, yes. You can see the full path in a little popup if you go to the "Files changed" tab and hover over the filename. |
These migrations have already been built and released with Bottlerocket releases and don't need to be built again. The build system and os package currently build everything in the migrations directory, which can take a significant amount of time with unneeded migrations. Their source is still useful as a reference, and the files are small, so it's worthwhile keeping them in-tree rather than having to search git history.
2615d66
to
f5a48c5
Compare
^ Rebase on develop to resolve conflict. |
Description of changes:
Testing done:
Before, building the os package took ~245 seconds:
After, takes ~190 seconds:
The difference in
rpm -qlp bottlerocket-x86_64-migrations-0.0-0.x86_64.rpm
is what you'd expect; before, it had all migration binaries back to 0.3.2:CLICK ME
After, only 1.1.0:
I did a
cargo make && cargo make repo
, with Infra.toml pointing at an existing repo to update, and looked at the result. Thetargets/
directory only has the new migration binaries, as you'd expect, which is fine - when you sync to update a repo you wouldn't delete existing target files. The manifest still has the full migration list, of course, since that's just taken from Release.toml literally. The targets.json metadata still includes the old migrations with the same hashes; the only difference (other than ordering) is the new images / kmod-kit I built.Terms of contribution:
By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.