New Copr release
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 ___ 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
Re: New COPR release
On Tue, 2017-02-28 at 15:33 +0100, Michal Novotny wrote: > Hey folks, > > updated COPR stack has been just deployed into production. This > included > several steps: > > 1) new release of copr-frontend (1.107-1) has been deployed > The main features of this release include re-enabling fedora-rawhide > as > chroot names, compatibility with python2-flask-whooshee-0.4.1-2, and > finally updates related to support of Module Build Service (MBS). What means this magic version number? is it some special build of flak- whooshee or what? > > 2) copr-backend was redeployed for mock 1.3.4 support > The backend configuration was updated to support the new mock 1.3.4. > Note > that fedora-26-* chroots will not work until the respective > repositories > are publicly available. Before, rawhide repositories were used for > f26 > chroots but today, that needed to be changed for the rawhide > branching. > Mainly because of this unpleasant config switching, we decided that > returning fedora-rawhide -* back is the best option. It will be kept > as > long as mock keeps it. We run on mock and we need to play with it > well. > Note that previous backend rawhide repositories are available in your > backend directories "-backup" suffixed. Otherwise, we are starting > from > scratch there and new repositories will be auto-created for the new > rawhide > builds. We are also starting fresh on copr-dist-git where the > previous > master branch has been renamed to master-backup and new master is > ready for > you. > > 3) a long-standing copr-keygen issue "Keygen service error" has been > hopefully fixed > This issue should no longer occur (at least not for the same reason). > Let > me know if it runs well. We'll see :) > > There are still unsolved network problems, which cause COPR to > underperform > these days while also requiring day-to-day copr-backend service > stop/starts. We are now going to debug these into depth. > > The ultimate goal now is to make COPR stable and reliable. > > Thank you > COPR team > ___ > copr-devel mailing list -- copr-devel@lists.fedorahosted.org > To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.o > rg -- -Igor Gnatenko signature.asc Description: This is a digitally signed message part ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
New COPR release
Hey folks, updated COPR stack has been just deployed into production. This included several steps: 1) new release of copr-frontend (1.107-1) has been deployed The main features of this release include re-enabling fedora-rawhide as chroot names, compatibility with python2-flask-whooshee-0.4.1-2, and finally updates related to support of Module Build Service (MBS). 2) copr-backend was redeployed for mock 1.3.4 support The backend configuration was updated to support the new mock 1.3.4. Note that fedora-26-* chroots will not work until the respective repositories are publicly available. Before, rawhide repositories were used for f26 chroots but today, that needed to be changed for the rawhide branching. Mainly because of this unpleasant config switching, we decided that returning fedora-rawhide -* back is the best option. It will be kept as long as mock keeps it. We run on mock and we need to play with it well. Note that previous backend rawhide repositories are available in your backend directories "-backup" suffixed. Otherwise, we are starting from scratch there and new repositories will be auto-created for the new rawhide builds. We are also starting fresh on copr-dist-git where the previous master branch has been renamed to master-backup and new master is ready for you. 3) a long-standing copr-keygen issue "Keygen service error" has been hopefully fixed This issue should no longer occur (at least not for the same reason). Let me know if it runs well. There are still unsolved network problems, which cause COPR to underperform these days while also requiring day-to-day copr-backend service stop/starts. We are now going to debug these into depth. The ultimate goal now is to make COPR stable and reliable. Thank you COPR team ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
New COPR release
Hey folks, it is our great pleasure to announce that newly released packages have just been deployed on COPR machines, that is: copr-frontend *1.105-1* copr-backend *1.96-1* copr-dist-git *0.24-1* These packages are f25 compatible (including copr-keygen) and offer some new features: copr-frontend: - always show "Regenerate" button for recreating backend repodata - display and improve info on modularity support in module details - handle GitHub tag event webhooks - option to login with krb5 now available copr-backend: - switched usage of deprecated ansible 1.x Runner for python-paramiko module to be compatible with ansible 2 - support for STOMP (Simple Text Oriented Message Protocol) for sending build info messages as an alternative to fedmsg copr-dist-git: - docker image upgraded to f25 You can find the complete list in the package changelogs, if required. To make a long story short, apart from upgrades to run on F25, there is also momentum to make COPR more general-purpose build system that can be installed and used on other distributions too. Modularity support is still a work in progress, although we are making some interesting progress. We are also continuously aiming to improve user experience. COPR team ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
