Skip to main content

5 posts tagged with "2024-October"

View All Tags

· One min read
Maja Massarini

Week 43 (October 22nd – October 28th)​

  • We have added support for retriggering jobs that are configured for commit and release trigger. Retriggering can be done via commit comments on the relevant commit, using the usual comments, such as /packit build or /packit test, but the branch or tag need to be specified like this (without the arguments, we will default to commit trigger for the default branch of the repository):

    /packit build --commit <branch-name>

    or

    /packit build --release <tag-name>

    (packit-service#2589)

  • There is a new method for getting a single commit comment, supporting also retrieval and adding reactions in GitHub. (ogr#865)

  • We have improved the feedback for the Open Scan Hub job. You can now see if the scan is in a pending, running, canceled, failed, or successful state. A failed or canceled scan is shown as neutral and does not cause your pull request validation to fail. (packit-service#2543)

· One min read
Matej Focko

Week 40 (October 1st – October 7th)​

  • packit validate-config now checks for the existence of the downstream package. (packit#2436)
  • Packit now allows building VM images via CLI without any Copr repository specified. (packit#2434)
  • We have unified interface of passing resolved bugs (e.g., Bugzillas as of now) to Packit CLI and via comments. Both CLI and comments now use --resolve-bug switch (comments accept comma-separated list of bugs, CLI accepts the switch multiple times (also -b)). (packit#2428 and packit-service#2560)
  • packit init now adds working directories that are used in packit prepare-sources into the .gitignore file in the same directory where Packit config resides. (packit#2431)
  • Before triggering the non-scratch Koji builds, we now check whether there is not already a build in progress or completed for the same NVR. (packit-service#2559)
  • We have improved the error reporting for failed downstream jobs. (packit-service#2544)
  • We have fixed an issue that caused inconsistencies with the expected behaviour stated by the documentation when adding duplicitous reactions to GitLab comments. (ogr#861)