Hello,
I am happy to announce a new Copr release. This time we have focused mainly
on improving a CI experience and freeing up some disk space, but there is
much more. These are some highlights from this release.
- CLI support for managing permissions
For quite some time, you have asked for a possibility to manage project
permissions through copr-cli or API. This is now possible, see
copr-cli request-permissions --help
copr-cli list-permissions --help
copr-cli edit-permissions --help
- Temporary projects
--
Many people use Copr for CI, which may include creating new projects.
Those are usually relevant for only a limited time and after that just
floods up the projects list. Instead of automatizing the deletion of
old projects all by yourself, try using temporary projects. When creating
or editing a project, it is possible to set an optional "Delete after days"
field in the Settings tab. There is also a command line option for this.
copr-cli create ... --delete-after-days
copr-cli modify ... --delete-after-days
- Automatic removal of old builds
---
Another feature useful for CI, but also for normal projects. Sometimes,
you don't care about old builds and they just slow working with
builds table. Avoid this by going to package settings and specifying
the optional "Max number of builds" parameter. Alternatively, use a
command line.
copr-cli add-package-* --max-builds
copr-cli edit-package-* --max-builds
This keeps last builds of this package. Older builds are
automatically deleted.
Note that our general policy for [builds
retention](https://docs.pagure.org/copr.copr/user_documentation.html#how-long-do-you-keep-the-builds)
still applies.
- Pagure CI fixes
Copr is for quite some time listening on fedmsg to react on PR and PUSH
events from Pagure (both src.fedoraproject.org and pagure.io).
However, previously
it had several limitations;
1) only the last commit from "push" or pull-request was analyzed, and thus
only builds for packages updated by _the last_ commit were triggered, this
is now fixed and copr analyses complete push/pull-request changes,
2) only one build per pull-reqeust could ever exist, this artificial rule
was relaxed and now each PR update (new commit, rebase, ...) triggers
a new copr build,
3) the fedmsg listener stopped receiving messages after some time and
a restart was needed, workaround for this was installed (and we plan to
move to fedora-messaging which should be more reliable),
4) there was a small rhbz#1699245 bug.
As a bonus point, it is now enough to add a pull-request comment with
`[copr-build]` keyword to manually (re)trigger the CI builds.
- Saving up some disk space
-
We are struggling with low disk space and hoping to free some up
by removing backend and distgit data for old builds. To be specific
- we are now removing:
* old SRPM import logs
* old tar files from dist-git look-aside cache
* SRPM from failed builds older than 14 days
- Turning off notifications for outdated chroots removal
--
Talking of disk space, we have recently started sending
notifications about an upcoming deletion of builds for outdated
chroots. The notifications suggest that if you still care about
an outdated distribution, going to project settings and prolong
the time for which the data is going to be preserved. If you don't
care about it and don't want to be bothered by emails, you can now
instantly expire the time and schedule the chroot to be removed.
- Respecting module buildorder
When building a module, the `buildorder` was not respected. This
issue is now fixed.
- Private data in separate tables
---
We have moved secret/private data about users and projects to
separate tables. This alone is not very interesting information.
However, it will allow us to dump our database (except for those
private tables of course) and share them to the public. This
will allow you to do custom data analysis and statistics.
Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
