-
Notifications
You must be signed in to change notification settings - Fork 84
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
[packit] Copr enhancements #872
[packit] Copr enhancements #872
Conversation
is_flag=True, | ||
) | ||
@click.option( | ||
"--preserve-project", |
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.
Could an option taking the number of days to preserve the project offer more flexibility? 0
could mean "preserve forever" while the default could be 60
.
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.
Tha will also save us some problems with overwriting since I am not sure (now) how I can unset the deletion.
But is it useful for users? I would say that they want to either preserve or remove automatically the project. Do they care about specific numbers?
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.
Why do we need to unset deletion?
Yeah, you have a point, maybe users don't care about the numbers that much, and if they do, it might be better to control those numbers in a separate option.
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.
Why do we need to unset deletion?
It can be useful when they don't know about that option in the time when the project is created or the option is not present (e.g. our project for master builds of packit has it said and we can't edit that via packit.)
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.
Based on the current help text I would expect expiration to be set only when the project is created by Packit:
Created copr project will not be removed after 60 days.
So when the Copr project already exists, I would expect this flag to have no effect.
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.
Ok, this will be tricky since no-value and default-value cannot be easily differentiated...
Build failed.
|
- list_on_homepage - preserve_project - additional_packages - additional_repos Signed-off-by: Frantisek Lachman <flachman@redhat.com>
- list_on_homepage - preserve_project - additional_repos The option additional_packages does not work yet since it's chroot specific. If the temporary option is switched to False, the deletion will probably not be disabled. Signed-off-by: Frantisek Lachman <flachman@redhat.com>
- --list-on-homepage - --preserve-project - --additional_repos Signed-off-by: Frantisek Lachman <flachman@redhat.com>
2c67bb3
to
c3abd2e
Compare
Build failed.
|
Will allow us to determine this in packit-service. Signed-off-by: Frantisek Lachman <flachman@redhat.com>
Congratulations! One of the builds has completed. 🍾 You can install the built RPMs by following these steps:
Please note that the RPMs should be used only in a testing environment. |
Build failed.
|
recheck |
/packit test |
Build succeeded.
|
Build succeeded (gate pipeline).
|
additional_packages
in config but it's not used yet. (Needs to be set per-chroot and will take more time to make it properly.)