Week 44-48 (November) 2019

With this blog post we’d like to continue with the idea of openly communicating changes in Packit. Since most of the developers use Packit as the GitHub App (which uses code from this repository - Packit Service), this blog will be about changes in all the parts, i.e. the GitHub App, the Packit Service and Packit itself.

Continuous Deployment (CD)

At the moment the workflow is that one of us manually triggers production container image build at the end of a week. This image is then automatically deployed into our production instance of the service over a weekend (Sun/Mon night) so that everyone can start a week with all the amazing stuff we added the previous week. In case an issue makes it through our staging instance into production uncaught, we can easily rollback on Monday. The same person also writes down what’s changed in Packit (service/app) since previous deployment.

Changes in production (since the end of November)

Previous post is almost half a year old so we won’t list all the changes since then, but only since last deployment, i.e. since end of December.

Packit

Previous deployment was running packit-0.7.1. We haven’t released a newer version since then, but in the service we install Packit from the Git repository (we have a separate stable git branch for our production deployment). From the most visible changes, Packit now:

  • better handles Create-archive action
  • is able to work in a repo with detached head
  • logs output from subprocesses in realtime
  • syncs config file and spec file by default in Propose-update action
  • hadles patches with undecodable chars

Packit Service

Now:

  • better reports Copr builds
    • uses separate commit status for srpm build and every chroot
    • clears test farm commit statuses when new build is triggered
    • better handles failed Copr builds
  • gracefully handles no config file in the repo
  • better handles when no (copr build) targets are specified in config file
  • better checks whitelist of users
  • does not create duplicate tickets in our notification repo when a new user install the app

Changes not visible to end users:

  • using Requre for integration/E2E tests
  • Fedora messaging consumer part of the service has been improved and moved to separate repo/image
  • using FAS instead of Fedora Badges for checking whether a user is Fedora packager
  • many improved logs
  • many bugs squashed
  • lot’s of code refactored