From #CentOSConnect: František Lachman talked about using Packit to automate builds on CBS Koji.
https://www.youtube.com/watch?v=RFxBy8SK_FE&list=PLuRtbOXpVDjDCM16tT5KHPbz3_Fy0vNzR&index=13
From #CentOSConnect: František Lachman and Siteshwar Vashisht talked about using OpenScanHub and Packit for static analysis.
https://www.youtube.com/watch?v=XYCh1hkCo-o&list=PLuRtbOXpVDjDCM16tT5KHPbz3_Fy0vNzR&index=7
Can't make it to Brussels but still want to discuss anything Packit-related?
Feel free to ping me on Matrix ([email protected]) or set up a quick video call with me at the following link:
calendar (DOT) app (DOT) google/ogTtHmLfJuKa49Q6A
What if detecting bugs and vulnerabilities in RPM-based distributions could be seamless and fully automated? OpenScanHub is a service for static and dynamic code analysis. It was internally used inside Red Hat to scan releases of RHEL for more than a decade and was open-sourced in 2023. OpenScanHub can fully automatically scan RPMs and has the ability to do differential scans that helps in finding bugs that may be introduced on package updates and new distribution releases. By default, it supports static analyzers embedded in GCC, Cppcheck, ShellCheck, find-unicode-control, Clippy and is extensible to support other analyzers. It can collect reports from various analyzers at a single place to make it easy to analyze them. OpenScanHub was recently integrated with Packit, a CI/CD solution for automating RPM package builds, tests, and distribution releases. This new integration performs differential scans on pull requests, so potential bugs may be found during the pull request review process and would not be introduced into the codebase. In this talk, we will share ideas about how CentOS Stream and its derivatives may benefit from OpenScanHub.
Wonder how many @packit PR you merged while automating your @fedora #Packaging #workflow ?
The #Pagure API does not let you answer this directly, so if you're wondering like me (or want to answer similar questions re: your PR activities), help is here!
$ ./distgit-pr-stats.py salimma --closed 2024-01-01..2025-01-01 --per-page 100 --requester packit --status Merged
https://michel-slm.name/posts/2025-01-07-distgit-stats/
This post is day 27 of my #100DaysToOffload challenge. Visit 100daystooffload.com to get more info, or to get involved.
Over the course of 2024, I’ve been increasingly adopting Packit’s pull-from-upstream for automating some package updates. I still think it should only be used judiciously - e.g. I generally only enable it for packages that do not embed code from other projects (necessitating license audits each time) and have good test coverage (because I’ll merge the PR if the test suite and installability checks both pass). Some packaging ecosystems that require the RPM spec to be regenerated each time (such as Rust) are disqualified by default. In fact, FESCo just voted today on the Automated Packit onboarding Change Proposal - and approved it provided it’s opt-in rather than opt-out, given these and similar concerns that several members share.
It is the last day of the year and time to reflect and recapitulate.
Multiple major features for Fedora automation, such as side-tag and non-git upstream support, and non-divergent branching.
🔒 New OpenScanHub integration for static analysis.
📈 Number of active projects was doubled.
📢 Team was present at multiple conferences.
Two Fedora Change proposals were submitted.
And much much more! 🎉
Take a look yourself: https://packit.dev/posts/packit-in-2024
Fedora is ~20000 packages. #Packit (the tool to autopackage directly from upstream) covers (I don't really know) let's say a 1000. Fedora gating (gating via a working rpm buiild) covers let's say 500.
This means everything else still uses direct push to dist-git as a main packaging step without verification. Until we change it, that's our pipeline.