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 <number>
      copr-cli modify ... --delete-after-days <number>


- 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 <number>
      copr-cli edit-package-* --max-builds <number>

This keeps last <number> 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
_______________________________________________
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org

Reply via email to