-
Notifications
You must be signed in to change notification settings - Fork 63
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
frontend: automatically EOL lifeless rolling chroots #3265
Conversation
frontend/coprs_frontend/alembic/versions/d23f84f87130_eol_rolling_builds.py
Fixed
Show fixed
Hide fixed
48947ff
to
ac1b4fd
Compare
341ddcf
to
48ac415
Compare
frontend/coprs_frontend/alembic/versions/d23f84f87130_eol_rolling_builds.py
Show resolved
Hide resolved
1211da6
to
7d7766f
Compare
7d7766f
to
1135fe8
Compare
1135fe8
to
13c5c74
Compare
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.
Thank you very much for the PR and I am sorry for late review.
Wow, the mechanism is complicated (not a fault of this PR, it was already complicated before). I don't know if it is worth simplifying somehow or moving to one place. Or better to keep as is.
I think I had a good idea with the ChrootDeletionStatus
back then. Maybe it would help us to have something like ChrootDeletionReason
to represent the descriptions in the last column of the "Logical implications per in-DB chroot state" table (e.g. requested_by_user
, rolling
, eol
). Or maybe even merging those two enums together and having one enum saying that the chroot is e.g. deleted_rolling
or preserved_manual
. Do you think it would help?
13c5c74
to
91bcab7
Compare
I resolved some of your remarks and marked the corresponding threads resolved. Can you PTAL? |
We could merge, but seems there's a problem with tests. Going to fix & merge. |
The `copr_chroot.deleted` value can not be true; the outer loop is skipped (`continue`) for deleted chroots.
When rolling policy finishes, we want to remove the data, but we also want to mark the CoprChroot.deleted (disable it from the project) because the corresponding mock chroot is still active in Copr. When user does a new build, we reset the CoprChroot delete_after/notification state, always. This is ok because during the normal MockChroot EOL policy, we do not allow new builds. Implements: https://github.com/fedora-copr/debate/blob/main/2024-04-23-rawhide-chroots-eol.md Fixes: fedora-copr#2933
91bcab7
to
1bd379b
Compare
This part is not not related to this PR, but #3314 - merging, thank you for the review!
|
Implements: https://github.com/fedora-copr/debate/blob/main/2024-04-23-rawhide-chroots-eol.md
Fixes: #2933