![\"Gemini](\"/assets/images/gemini_ref-541e4ee378d41e92f9999bd9086959be.png\")
One amazing benefit that modern LLMs come with is using them as a linter, or a pair programmer. You can easily get feedback on your code: just share it with the AI tool and ask a question. If the feedback is solid, your code is improved. If the feedback is poor, you can just disregard it. But overall with very little effort you can gain a lot.
In this article we are going to focus on code review done with AI tools. We are going to explore a few solutions available as of February 2026 and how they compare based on our experience. This is not a thorough analysis nor are we doing any evals.
Our AI tool of choice for our upstream reviews is Gemini-code-assist. It's free, easy to set up, and you get to see the comments inside the GitHub interface. Since it's powered by the Gemini models, it can provide solid feedback. If your PR contains clear mistakes, this tool can easily find them. On top of that, we had multiple instances when Gemini discovered subtle issues that were not obvious to the author or a reviewer which turned out to be real problems. Therefore it prevented real bugs from happening in our production environment.
On the other hand, it can be quite opinionated with suggestions that are either irrelevant or don't match your project. That's not strictly a bad thing. Gemini often brings up technical debt and comments on complexity of pull requests. These comments can start a very productive discussion and help the team battle technical debt and invent solutions that can be easily maintained long term.
Jiri Podivin recently contributed a style guide to help Gemini with the reviews. Over the few weeks we only saw a handful of occasions when Gemini would take it into account:
It's possible to run this tool locally in your IDE, but if that's not your local development workflow, it's easier to just open a PR.
But overall, Gemini-code-assist is an amazing tool that is easy to set up, easy to use, it's free and provides real benefit.
Let's continue with the well known Claude Code tool. It's a full-blown AI agentic system running in your terminal, so it can perform code review easily. You don't even need a fancy prompt, it can be as simple as:
Perform a thorough code review of our latest work in commit 4b50c430861020216befeecafaebb918ac7bda1f
Claude will inspect the commit and will create a plan for itself with tasks to accomplish the code review. It can look something like this:
● Bash(git show 4b50c430861020216befeecafaebb918ac7bda1f --stat)
⎿ commit 4b50c430861020216befeecafaebb918ac7bda1f
Author: Tomas Tomecek <ttomecek@redhat.com>
Date: Fri Feb 13 10:38:14 2026 +0100
… +22 lines (ctrl+o to expand)
● Bash(git show 4b50c430861020216befeecafaebb918ac7bda1f)
⎿ commit 4b50c430861020216befeecafaebb918ac7bda1f
Author: Tomas Tomecek <ttomecek@redhat.com>
Date: Fri Feb 13 10:38:14 2026 +0100
… +395 lines (ctrl+o to expand)
● Thorough Code Review: Commit 4b50c43 \"Implement feature foobar\"
🔴 CRITICAL ISSUES
1. SYNTAX ERROR: Invalid Jinja2 Expression
...
The biggest advantage here is that if you are already using this tool (or something similar), it's just a natural part of your development workflow. Claude Code not only reviews your work, but it can also propose changes and even implement them.
This tool can be infinitely helpful, especially if your codebase is easy to navigate, is not colossal, and has solid documentation which Claude can follow.
Several people on the team use Claude Code daily and it is part of our daily job. We've gotten used to it so much that we couldn't live without it, honestly. It's so convenient and helpful. But not everyone is using it, with so many AI tools available, our personal journeys with AI tools adoption are different.
Though not everything it does is perfect and we always need to review its work and update it.
Another huge benefit here is that creating a slash command with precise description and expectations about the review is not hard. Then you can get reviews tailored specifically for you.
We have already started a repository where we gather our Claude Code slash commands: github.com/packit/internal-ai-workflows
ai-code-reviewThis is a tool built by a Redhatter Juanje Ojeda. It's a command-line tool that works with multiple AI providers (Gemini, Vertex AI, Anthropic, Ollama) and can perform code review locally or on existing pull requests on GitHub or GitLab.
I love the simplicity: you set it up once and then with a simple command you can have local code review and also set it up in your CI system. If you are a fan of the UNIX philosophy of having a single tool that does its job well, then this is the one.
Here's an example usage for a local change for this blog post:
$ ai-code-review --local
📝 Review generated successfully!
================================================================================
AI CODE REVIEW
================================================================================
## Local Code Review
### 🔍 Code Analysis
This merge request adds a blog post about AI-powered code review tools...
### ✅ Summary
**Overall Assessment:** No critical issues identified. This is a low-risk content addition with proper documentation and minimal dependency changes. Minor suggestions provided for content improvements and link verification.
**Minor Suggestions:**
- Consider adding version pinning to requirements.txt for reproducibility (e.g., pygal==3.0.0)
- Verify the February 2026 date in the blog post is intentional and not a typo
- Check that external links (especially github.com/packit/internal-ai-workflows) are accessible to intended readers
- Consider adding alt text description in the markdown for the gemini_ref.png image for accessibility
- The blog post could benefit from a brief mention of evaluation criteria used when comparing the tools
---
🤖 **AI Code Review** | Model: claude-sonnet-4-5
⚠️ AI-generated suggestions may be incorrect. Verify before applying.
I've omitted the detailed code analysis section here for brevity, but the summary gives you a good sense of the output quality and structure.
The tool is particularly valuable if you're cautious about sharing data with Cloud providers. You can run a model of your choice locally via Ollama and be completely self-sufficient.
While the summary output is well-structured, as shown above, the full detailed review can be quite verbose. Some additional formatting options (especially syntax highlighting and usage of colors), or the ability to adjust verbosity levels would be helpful for quickly scanning larger changes.
With that said, ai-code-review is a powerful tool that serves its purpose very well. Since it's an open-source project, you're welcome to open issues or contribute improvements.
We're aware of CodeRabbit, another well-known AI code review tool, but haven't had the opportunity to evaluate it yet. We may cover it in a future post.
We've explored three distinct approaches to AI-based code review: Gemini-code-assist for seamless GitHub integration, Claude Code for comprehensive development assistance, and ai-code-review for maximum flexibility.
Our recommendations:
Each tool excels in its domain, and the \"best\" choice depends on your workflow, privacy requirements, and how you want AI to fit into your development process. The important thing is to start incorporating AI code review into your workflow. Every review comment that AI catches is time and energy your team can redirect toward more valuable work, such as having a cup of coffee.
Even though this article was written by me, Tomas Tomecek, I captured the feedback of all the team members I received over the past several weeks.
", "url": "https://packit.dev/posts/code-review", "title": "Our experience with AI-based code review", "summary": "One amazing benefit that modern LLMs come with is using them as a linter, or a pair programmer. You can easily get feedback on your code: just share it with the AI tool and ask a question. If the feedback is solid, your code is improved. If the feedback is poor, you can just disregard it. But overall with very little effort you can gain a lot.", "date_modified": "2026-06-09T11:51:53.000Z", "author": { "name": "Tomáš Tomeček", "url": "https://github.com/TomasTomecek" }, "tags": [ "AI", "code-review", "automation", "development" ] }, { "id": "https://packit.dev/posts/comparing-frontier-models-june2026", "content_html": "We evaluated three Claude frontier models: Sonnet 4.6, Opus 4.6, and Opus 4.8.\nThis was done on a fixed set of five RHEL triage issues using our end-to-end\ntest\nharness. The\nharness is validating our triaging agent against a fixed set of known issues.\nTriage is the first and most consequential step in the workflow: the agent reads\na Jira CVE issue and decides how it should be resolved — backport an upstream\npatch, rebase to a newer version, or mark it as not-affected. A wrong call here\ninvalidates everything downstream, which is why it's the natural starting point\nfor a model benchmark.
The 4.6 models ran with REASONING_EFFORT=high, which enables native extended\nthinking. Opus 4.8 ran without it — a LiteLLM/BeeAI provider ID mismatch caused\nthe model to reject the thinking parameter, so we disabled it entirely\n(tracked here). The harness runs all five issues concurrently and captures per-issue\nmetrics from the agent framework: wall-clock duration, tool call count, and\ntotal token usage.
This is the first time we've done this kind of work and it was quite a learning\nexperience. This blog post contains data from a single run with each model.
I already have ideas for improvement for a future run. We need to extend the\nscope to backporting agent as well and have at least ten cases. Doing multiple\nruns per model with aggregation would also give us more grounded results.
All three models reached identical conclusions on all five issues. The triage\ndecisions were unambiguous: three backports (RHEL-15216, RHEL-112546,\nRHEL-177992) and two not-affected (RHEL-114607, RHEL-174694). RHEL-114607 is\nworth highlighting — the issue concerns CVE-2025-59375 in expat, which only\naffects versions before 2.7.2. RHEL 10 already ships 2.7.3, so the models\ncorrectly concluded not-affected rather than recommending a rebase to 2.7.5.
Sonnet 4.6 was the fastest model on four of the five issues, sometimes by a\nlarge margin. RHEL-112546 illustrates the biggest spread: Sonnet resolved it in\n98s with just 9 tool calls, while Opus 4.6 took 267s and 37 tool calls, and\nOpus 4.8 took 154s and 25 tool calls. Both Opus models invested significantly\nmore effort on this libtiff CVE, exploring more patch URLs and performing\ndeeper code analysis.
RHEL-174694 shows the opposite pattern: Opus 4.8 took 389s with 17 tool calls —\nmore than twice Sonnet's 167s — despite using fewer tool calls. The extended\nthinking budget appeared to cause the model to deliberate at length before\nsettling on a conclusion that Sonnet reached more directly.
Opus 4.8 is consistently faster than Opus 4.6 (except for RHEL-174694), which\nsuggests the architecture improvements between the two generations translate\ninto more efficient reasoning chains.
The stark difference between the numbers is not just caused by the model\nevolution but also the fact how non-deterministic task this triage is. We are\nalso not utilizing Opus 4.8's adaptive thinking.
The token numbers reveal a notable pattern: Opus 4.8 uses more input tokens\nthan Opus 4.6 for the same issues, but far fewer output tokens. On\nRHEL-112546, Opus 4.6 produced 11,268 output tokens versus Opus 4.8's 5,864\n— the newer model reasons more concisely even when it reads more context.
Cost differences are significant but concrete numbers highly depend on the\nactual plan.
For the triage workload we tested, Sonnet 4.6 offers the best price-performance\nratio by a wide margin. Opus models invested more in investigation on hard\nissues but did not produce different conclusions. Opus 4.8's speed advantage\nover Opus 4.6 is real but does not close the cost gap.
On the other hand, this is an evaluation harness, so we need to make a real\njudgement in our day to day work while processing real issues.
None of this analysis would be possible without the incredible work of the\nwhole team and especially Tomas Korbar who\nauthored the E2E test suite, Ondrej Pohorelsky\nwho contributed the initial support for Opus 4.8 to\nai-workflows, Nikola\nForro - author of our minimal trace-server, Laura\nBarcziova whose scripts and Claude skills I\nused for this research, Matej Focko for consulting\nwith me all the time, and Maja Massarini\nfor the polished Makefile & compose setup that carried the test runs.
", "url": "https://packit.dev/posts/comparing-frontier-models-june2026", "title": "Comparing frontier Claude models for our AI workflows (June 2026)", "summary": "We evaluated three Claude frontier models: Sonnet 4.6, Opus 4.6, and Opus 4.8.", "date_modified": "2026-06-09T11:51:53.000Z", "author": { "name": "Tomáš Tomeček", "url": "https://github.com/TomasTomecek" }, "tags": [ "AI", "automation", "development", "eval" ] }, { "id": "https://packit.dev/posts/multiple-release-streams", "content_html": "There are upstream projects that have multiple release streams and, for example, regularly release\npatch versions for every active minor version. With\npull-from-upstream you have been able\nto follow only the highest stream, but that now changes. By switching\nMonitoring status\nof your package from Monitoring to Monitoring all, you enable triggering\npull-from-upstream\nfor every released version, not only the highest. This means you can use options such as\nversion_update_mask,\nupstream_tag_include or\nupstream_tag_exclude (those require\nupstream_project_url to be set)\nto filter a specific release stream you want to follow, or have multiple\npull-from-upstream jobs,\neach matching different releases and targeting different dist-git branches.
Instead of changing Monitoring status in the dist-git web UI, you can have a\nmonitoring.toml\nfile in the rawhide branch in dist-git and set all_versions = true to trigger\npull-from-upstream for all released versions.
For an upstream project releasing 1.7.z and 1.6.z streams, you could configure the jobs like this:
jobs:
- job: pull_from_upstream
trigger: release
upstream_tag_exclude: ^v1\\.6\\.\\d+$
dist_git_branches:
- fedora-rawhide
- job: pull_from_upstream
trigger: release
upstream_tag_include: ^v1\\.6\\.\\d+$
dist_git_branches:
- fedora-branched
With this configuration security backports to the 1.6 upstream branch would result in Packit opening dist-git PRs\nagainst branched Fedoras while for any other release Packit would open dist-git PRs in Rawhide.
We have introduced a new configuration option\nversion_update_specifiers.\nIt borrows syntax of\nPEP440 version specifiers\nand gives you more flexibility when filtering release streams. For example:
jobs:
- job: pull_from_upstream
trigger: release
# 3.y.z or higher versions go to Rawhide
version_update_specifiers: >=3.0
dist_git_branches:
- fedora-rawhide
- job: pull_from_upstream
trigger: release
# versions 2.y.z go to stable Fedoras, excluding a known broken version
version_update_specifiers: ~=2.0, !=2.5.4
dist_git_branches:
- fedora-branched
We are happy to announce that the ogr library now supports yet another open-source git forge — Forgejo. This brings the total number of supported forges to four. Thank you to all external contributors and especially mynk8 who helped to turn this part of the project into reality!
Ogr stands for One Git library to Rule. It is a library offering a unified API for multiple git forges, meaning that it makes it possible to communicate with all supported git forges using the same set of methods. Historically, the list of supported forges consisted of GitHub, GitLab and Pagure. This list has now been expanded to include Forgejo as well.
Here is a short example showcasing how to create a new issue in a repository using ogr:
from ogr import ForgejoService
service = ForgejoService(instance_url=\"https://codeberg.org\", token=\"...\")
project = service.get_project(namespace=\"owner\", repo=\"repo\")
project.create_issue(title=\"Issue title\", body=\"Issue description\")
For more information see our documentation and Jupyter notebook examples.
With the added support of Forgejo in ogr, it is now possible for us to work on support of Forgejo as dist-git in Packit. If interested, you can track our progress on the upcoming addition in this epic.
", "url": "https://packit.dev/posts/forgejo-in-ogr", "title": "Forgejo is now supported in ogr", "summary": "We are happy to announce that the ogr library now supports yet another open-source git forge — Forgejo. This brings the total number of supported forges to four. Thank you to all external contributors and especially mynk8 who helped to turn this part of the project into reality!", "date_modified": "2026-02-10T13:00:00.000Z", "author": { "name": "Alžběta Kučerová", "url": "https://github.com/betulependule" }, "tags": [ "Forgejo", "ogr" ] }, { "id": "https://packit.dev/posts/lessons-learned-ai-automation-rhel", "content_html": "After building and running AI-powered automation for RHEL package maintenance workflows (available in this repo), our team has learned a lot about what it takes to move from impressive demos to a reliable production system. Here are the key insights that might save you time and frustration on your own AI automation journey.
When we started this project, the number of AI frameworks available was both exciting and overwhelming. We experimented with multiple approaches:
The reality? Every framework has trade-offs, and the “best” choice depends heavily on your specific use case. Goose was great for rapid prototyping and was an excellent starting point choice, but we quickly discovered we needed something more robust for production. With so many options available, we went with something we were able to easily start with and still achieve good results. BeeAI's structured approach with conditional requirements and many more possibilities of restrictions and control over agents proved more suitable for our complex, multi-step workflows.
Since security is very important for the production-level system, and it's also easy to create your own MCP server, we've opted for that option so the code is 100% controlled by us. This way, we can define exactly which Jira fields can be touched, what values are allowed, and under what conditions. Agents get an exact list of functions they can use, and none of them have any credentials in their environment: everything that needs authentication goes through MCP.
Lesson learned: Don't get stuck in analysis paralysis. Pick a framework that aligns with your team's expertise and iterate. You can always migrate later (and we did).
AI agents can be incredibly impressive in demos. Show someone an agent that can analyse a Jira issue, determine it needs a backport, find the upstream patch, and apply it automatically - and they'll be amazed. As we were amazed too. But making that work reliably in production? That's where the real work begins.
Our triage agent, which analyses Jira issues and decides follow-up actions, for example, has a 150+ line prompt with detailed decision trees:
# From Triage Agent - just a snippet of the complexity
\"\"\"
**Decision Guidelines & Investigation Steps**
You must decide between one of 5 actions. Follow these guidelines:
1. **Rebase** - Only when issue explicitly instructs to \"rebase\" or \"update\"
2. **Backport a Patch OR Request Clarification**
2.1. Deep Analysis of the Issue
2.2. Systematic Source Investigation
2.3. Validate the Fix and URL
2.4. Decide the Outcome
3. **No Action** - For non-bugs (QE tasks, features, docs)
4. **Error** - Processing issues preventing analysis
\"\"\"
What looks like a simple “analyse this issue” task actually requires:
Lesson learned: Don't let demo success fool you into underestimating production complexity.
Like many AI projects, we started with the foolish idea of building one super-agent that could handle everything. Fortunately, we realised very quickly that this just isn't possible - at least not reliably.
Our foundation became three core agents, which proved to be an excellent starting point:
But as we started encountering specific production issues and as these agents grew increasingly complex with corner cases and real-world requirements, we began implementing even more specialised agents that integrate seamlessly with our main three.
The Log Agent is a perfect example of this evolution. Instead of having the backport and rebase agents figure out how to document their changes (adding yet another responsibility to already complex workflows), we created a dedicated specialist:
# This is just a snippet from the Log Agent instructions
\"\"\"
You are an expert on summarizing packaging changes in RHEL ecosystem.
To document a change:
1. Use `git diff --cached` to see the final changes staged for commit
2. Add a changelog entry to the spec file with proper formatting
3. Generate a commit message title (max 80 characters)
4. Summarize changes for the merge request description
\"\"\"
This specialisation journey is still ongoing, and we can absolutely see opportunities to create even smaller, more focused agents. Each new specialised agent makes our workflows more robust and our main agents cleaner and more reliable.
Lesson learned: Start with a small number of core agents, but don't be afraid to extract specialised functionality as complexity grows.
We've experimented with multiple models, providers and settings:
gemini-2.5-pro)claude-sonnet-4)Yes, newer models often perform better, and it's worth trying them. But here's what matters more:
For example, our backport agent doesn't just “apply a patch” - it has a sophisticated workflow and tools:
# Specialized tools for reliable patch handling
tools=[
GitPatchCreationTool(options=local_tool_options),
GitPatchApplyTool(options=local_tool_options),
GitPatchApplyFinishTool(options=local_tool_options),
GitLogSearchTool(options=local_tool_options),
GitPreparePackageSourcesTool(options=local_tool_options),
# ... more specialized tools
]
Lesson learned: Invest time in tooling and architecture.
This might be the most important lesson: AI agents will never be 100% deterministic, and that's actually okay for many use cases. But you need to be strategic about where you accept non-determinism and where you demand consistency.
Examples where we embrace AI non-determinism:
Examples where we use deterministic code:
Lesson learned: Design your system to be “AI-assisted” rather than “AI-controlled”. Use AI for the creative, analytical work, but rely on deterministic code for the critical operations.
Once you move from building a prototype to building a production system, you also need to think about the infrastructure and other components, not just agents and code around them. Here are just a few examples of what we architected that keeps AI agents running reliably:
Lesson learned: Start thinking about operational capabilities on day one. Dry-run modes, proper logging, and failure recovery aren't “nice to haves” - they are what makes AI systems actually usable. And since LLMs produce a ton of output, you'll need an efficient way to find out why the agents made such an odd decision.
After roughly 3.5 months of development, our system is currently running for a selected set of components - and it's being heavily developed. But by following these principles, we've seen a huge difference in reliability and maintainability. More importantly, we're now much clearer about what's actually possible to do with AI and what isn't.
Ask me again in 3 months, and I'll probably have another set of valuable lessons learned. But that's the nature of this rapidly evolving field.
", "url": "https://packit.dev/posts/lessons-learned-ai-automation-rhel", "title": "Lessons learned: Building production AI automation for RHEL package maintenance", "summary": "After building and running AI-powered automation for RHEL package maintenance workflows (available in this repo), our team has learned a lot about what it takes to move from impressive demos to a reliable production system. Here are the key insights that might save you time and frustration on your own AI automation journey.", "date_modified": "2025-10-05T23:00:00.000Z", "author": { "name": "Laura Barcziová", "url": "https://github.com/lbarcziova" }, "tags": [ "AI", "automation", "RHEL" ] }, { "id": "https://packit.dev/posts/specfile-advanced", "content_html": "Are you already familiar with the basic concepts of the specfile library?\nThen welcome to a collection of some slightly more advanced topics that you could find useful.\nIf you're not that familiar and would like to start with something easier,\nyou can take a look at Introduction to specfile library.
Imagine you want to make changes to a spec file that requires some sources\nto be present at the time of parsing such as sources referenced from shell\nexpansions (e.g. %(date +%F -r %{SOURCE0})), includes some external files\nusing the %include directive, or loads external macrofiles with the %load macro,\nbut all you have is the spec file itself.
In such case you may want to instantiate Specfile with the force_parse argument\nset to True in order to attempt to parse the spec file with missing external files.\nIf that succeeds and some required external files were indeed missing during parsing,\nthe Specfile.tainted property is set to True to indicate that certain assumptions\ncould be broken - for example a condition that relies on a macro defined in an external\nmacrofile could be evaluated incorrectly.
You can define or undefine any RPM macros before parsing a spec file with the macros\nargument to the Specfile constructor. The argument takes a list of 2-string tuples\nwhere the first element is macro name and the second element is macro value.\nIf the second element is None, the macro will be undefined. This can come in handy\nwhen you need to undefine a system macro such as fedora.
from specfile import Specfile
spec = Specfile(
\"example.spec\",
macros=[
(\"fedora\", None),
(\"epel\", \"9\"),
],
)
It is also possible to pass macro definitions in the same format as the extra_macros\nargument to the Specfile.expand() method in order to temporarily define or undefine macros\nbefore expression expansion.
For example, the following code snippet will print the expanded value of the Release tag\nwithout system dist tag:
spec = Specfile(\"example.spec\")
print(spec.expand(\"%release\", extra_macros=[(\"dist\", None)]))
This is just for demonstration of extra_macros, you can achieve the same with:
spec = Specfile(\"example.spec\")
print(spec.expanded_release)
MacroDefinition, Tag, SourceListEntry, Source and Patch classes have a valid attribute\nthat determines if the respective entity is in a true branch of a condition (provided that the condition\nis not present in a false branch of another condition).
Having the following in a spec file:
%if %{defined copr_username}
Epoch: 102
%else
Epoch: 2
%endif
You can use the Tag.valid attribute to choose the suitable Epoch tag based on validity:
from specfile import Specfile
spec = Specfile(\"example.spec\")
with spec.tags() as tags:
epoch_tags = [t for t in tags if t.normalized_name == \"Epoch\"]
# print the value of the first Epoch tag, disregarding the condition
print(epoch_tags[0].value)
# print the value of the first valid Epoch tag
print(next(t for t in epoch_tags if t.valid).value)
# when accessing tags by name the first valid one is chosen,
# so this does the same as above
print(tags.epoch.value)
You can get expanded values of tags with their expanded_value property. This is the literal\nvalue of a tag as present in the spec file that is passed to Specfile.expand() for expansion.
If you are not interested in modification and want to get exactly what rpmspec --parse example.spec\nwould give you, you can use the Specfile.parsed_sections property:
spec = Specfile(\"example.spec\")
with spec.tags(spec.parsed_sections.package) as tags:
print(tags.version.value)
Doing this means that all conditions and macros will be already expanded, so all tags will be valid\nand their value and expanded_value will be the same. Modifications will have no effect.
You can also access the underlying rpm.spec object with the Specfile.rpm_spec property,\nwhich allows you to do things like:
spec = Specfile(\"example.spec\")
print(spec.rpm_spec.sourceHeader.epoch)
In this case the printed value will be a number, not a string like in previous cases.
This means you have 3 ways how to get expanded value of a tag with the specfile library.\nAll of them should give you same or very similar results, but only the first one gives you access\nalso to the unexpanded value of a tag and the possibility to modify it. On the other hand it will\nalso take the most time, so think twice if performance is a concern.
Consider the following in a spec file:
#global rc_ver 3
%global maj_ver 12
%global min_ver 0
%global patch_ver 1
Name: %{pkg_name}
Version: %{maj_ver}.%{min_ver}.%{patch_ver}%{?rc_ver:~rc%{rc_ver}}
Rather than replacing the value of Version with a version string, removing all the macro\nsubstitutions in the process, you can use Specfile.update_tag() and have it try to update\nthe relevant macro definitions instead:
from specfile import Specfile
spec = Specfile(\"example.spec\")
spec.update_tag(\"Version\", \"12.1.0\")
This will result in:
#global rc_ver 3
%global maj_ver 12
%global min_ver 1
%global patch_ver 0
Name: %{pkg_name}
Version: %{maj_ver}.%{min_ver}.%{patch_ver}%{?rc_ver:~rc%{rc_ver}}
It will even uncomment a commented-out macro definition if needed:
spec = Specfile(\"example.spec\")
spec.update_tag(\"Version\", \"12.1.1~rc1\")
This will result in:
%global rc_ver 1
%global maj_ver 12
%global min_ver 1
%global patch_ver 1
Name: %{pkg_name}
Version: %{maj_ver}.%{min_ver}.%{patch_ver}%{?rc_ver:~rc%{rc_ver}}
However, if you want to go back to a regular version, you have to comment out the relevant\nmacro definition explicitly:
from specfile import Specfile
from specfile.macro_definitions import CommentOutStyle
spec = Specfile(\"example.spec\")
with spec.macro_definitions() as macro_definitions:
# use the original comment-out style
macro_definitions.rc_ver.comment_out_style = CommentOutStyle.HASH
macro_definitions.rc_ver.commented_out = True
spec.update_tag(\"Version\", \"12.1.1\")
This will result in:
#global rc_ver 1
%global maj_ver 12
%global min_ver 1
%global patch_ver 1
Name: %{pkg_name}
Version: %{maj_ver}.%{min_ver}.%{patch_ver}%{?rc_ver:~rc%{rc_ver}}
The algorithm isn't perfect and won't work in all situations, but even if it's not possible to update\nsome macro definitions it is guaranteed that expanded_value of a tag after calling update_tag()\nwill be equal to the given value.
There is also a more general method Specfile.update_value() that allows you to update any string\nwithin a spec file in the same manner, trying to preserve macro substitutions and update relevant\nmacro definitions (or even tag values in case of e.g. %{version}) if possible. It is up to you\nto replace the original string with the result (that can but doesn't have to be exactly the same).
The algorithm first tokenizes the string to be updated. Then it determines which macro substitutions\nwithin the string can be affected by modifying bodies of preceding macro definitions or values\nof preceding tags. Then it identifies substrings that are deemed modifiable (that could be for example\na sequence of numbers between two dots) and constructs a regular expression in which the modifiable\nmacro substitutions and the modifiable substrings are capturing groups.\nIf the requested new string is a not match to this regular expression, nothing happens and the requested\nnew string is returned unchanged. If it is a match though, the captured groups corresponding to modifiable\nmacro substitutions are processed, recursively, starting with tokenization once again. The requested\nnew string is then updated with corresponding macro substitutions from the original string and returned.
Are you interested in more details, trying the library out or even contributing?\nYou can find specfile source code on GitHub.\nSee the README for more tips and usage examples.\nYou can also check out the API reference.
", "url": "https://packit.dev/posts/specfile-advanced", "title": "Advanced usage of the specfile library", "summary": "Are you already familiar with the basic concepts of the specfile library?", "date_modified": "2025-01-09T00:00:00.000Z", "author": { "name": "Nikola Forró", "url": "https://github.com/nforro" }, "tags": [ "specfile" ] }, { "id": "https://packit.dev/posts/packit-in-2024", "content_html": "We are reaching the end of the year and it’s a good time to look back at the Packit highlights of this year. And it was a year!
We didn’t take a winter sleep, and at the very start of the year, we announced the Python library for parsing specfiles. (Mainly written by Nikola.) We had been successfully using it for some time and it was time to give the benefit to others. Thanks to that, there is now a language Server for RPM spec files.
A lot usually happens in Brussels at the turn of January and February. And this time, we were present as well for the first time. František (joined by Evgeny) presented on CentOS Connect how Packit and Testing Farm can be beneficial to the CentOS community. Also, at this conference, there was a meetup of the CentOS Integration SIG which Matej and František joined. The main event in Brussels is the FOSDEM conference, a big conference consisting of multiple so-called rooms. František took an interactive session in the Distribution room about the relationship between upstream and downstream.
During the whole year, we have made many improvements so more packages can use Packit’s Fedora release automation. Since many packages can benefit from Packit right away, we’ve introduced an onboarding command capable of preparing a configuration file and also moving it to dist-git – either via pull requests or direct push.
For some time, Packit has been able to build VM images thanks to the prototype integration with the Image Builder service. To promote this functionality and see if there is enough demand to continue development, Maja prepared a blog post for RedHat’s Developer Portal (also available on Packit’s webpage).
As each year, the team met in person in June in Brno – both to gather and discuss Packit-related topics and also to be part of DevConf.CZ conference. To not need to dive into everything happening during that time in this text, take a look at our blog post. We organised a successful workshop in the Red Hat Brno office and took multiple talks, notably a showcase of user success stories presented by our fellow users.
During summer and again after a couple of years, we had the pleasure to have a student working on a Packit-related task as part of the Google Summer of Code. This time, the functionality was going outside of the Fedora ecosystem, namely to support OBS (the openSUSE build and distribution service). We want to thank Brian Elle who worked on this, and Dan Čermák who took the lead on this from the openSUSE side and is currently polishing the code so it can be introduced into Packit’s codebase without worrying about maintainability.
Another regular event during the year is a Fedora yearly conference – Flock. This time happening in Rochester and thanks to Fedora’s sponsorship, both Laura and František could take part. Similar to DevConf.CZ we’ve covered all the details in a separate blog post. Just to mention the talks presented, we took one session covering Fedora automation and our journey to it and a second one with Jan Havlín from the Testing Farm to show people various testing use cases and all the news that was delivered on this field.
The second half of the year was spent finishing all the initiatives we’d worked on for some time. The long-awaited feature was not to require a git upstream for Fedora release automation. This wasn’t so simple because of the old decision to build Packit on the concept of related git repositories – one representing upstream and one downstream. (And maybe one for the source-git, but that’s a story for another time.) Luckily, all the hard work was done and many packages can now use Packit.
Another feature and another change of Packit’s internal plumbings is the way to avoid having divergent branching when releasing to multiple Fedora (or EPEL) branches. Thanks to this, the commits between branches can now be shared and the history can be linear.
This is still not all. Another huge feature spreading across multiple packages is the support for side-tags. It’s a vast improvement and enabler for various package groups that need to control many packages together. And it’s finally there!
And this is still not all for this year. We love collaborating on features and one such collaboration was/is with Siteshwar Vashisht on integrating Packit with OpenScanHub so Packit users can run static analysis without much effort. Later during the year, we managed to properly report differential scans (so you can check only new findings.) If you are interested in this (or would like to know why one needs to care), look at Situ’s presentation on DevConf.CZ or Cauldron conference. You can also visit Brussels next year and František and Siteshwar Vashisht should present the integration on the CentOS Connect. Feedback for this functionality is welcome here.
After all these big achievements and many small and big improvements, the time has come to release Packit v1.0.0. Everything is now prepared, and we are giving people time to update their configuration files. (Since we love automation and pull request-based workflows, the affected users should have received a pull request with the changes required.)
So, quite a strong year, wasn’t it?
If you rather want to check some hard data, let’s look at the usage trend charts from last year. We’ve managed to double the number of projects! As you can see, there is a strong trend in the Fedora automation space overnumbering the projects with upstream Copr builds and/or tests.
![\"Trend](\"/assets/images/2024-onboarding-chart-79dab44b5c3b112d3d062fb63872ed43.png\")
And now, we are slowly moving towards the next year. So, what you can expect from us?
We have two ideas on how to have a bigger impact (a positive one, we truly believe) in Fedora. Since we believe Fedora is about community, we have prepared two Fedora Change Proposals so everyone can provide feedback on what we would like to introduce.
We would also like to give our dashboard more love. We used to prioritise other features, but we can’t postpone it forever. With the help of Freya, we plan to start with user research and try to make the dashboard more user-friendly as part of Project Mycorrhiza.
To be closer to Fedora, we would also like to move our deployments to the Fedora OpenShift Cluster. The discussions are ongoing, and luckily, we might be able to do this soon.
And if you want to meet us in person, a good chance is CentOS Connect, DevConf.CZ or Flock.
Hopefully, the following year will be at least as successful as the previous one. Thanks everyone for your support. We have the pleasure to have a friendly and grateful userbase that is a pleasure to work with and for. All the best for the new year!
", "url": "https://packit.dev/posts/packit-in-2024", "title": "Packit in 2024", "summary": "We are reaching the end of the year and it’s a good time to look back at the Packit highlights of this year. And it was a year!", "date_modified": "2024-12-23T00:00:00.000Z", "author": { "name": "František Lachman", "url": "https://github.com/lachmanfrantisek" }, "tags": [ "2024", "yearly-features", "summary" ] }, { "id": "https://packit.dev/posts/packit_1_0_0_action_required", "content_html": "After 105 minor releases we are almost ready to announce our first major release, Packit 1.0.0!
We will remove all long-deprecated keys from the configuration file.
packit-service jobs are tied with packit CLI. The packit configuration code is defined in the packit package and used by the packit-service.\nSo be aware that for those projects still using the deprecated keys in their packit.yaml configuration file we have created a migration pull request.
Please, check if you have any new PR for your project created by the packit-service bot account, review and merge it. Otherwise, you might experience issues with the packit-service jobs once the new packit version is released.
We plan to release Packit 1.0.0 in January 2025.
build has been changed to copr_build.production_build has been changed to upstream_koji_build.upstream_project_name has been changed to upstream_package_name.synced_files has been changed to files_to_sync.The job types were renamed for clarity when we introduced more job types.\nThe upstream_project_name was renamed to upstream_package_name to be more specific.\nThe files_to_sync key has a more explicit behavior than the old synced_files key.
This term has been thrown around a bit in issues here and there relating to the dashboard and\npeople usually get confused, and rightfully so! Lets dive in and see what Project Mycorrhiza\nis and why we chose this name.
![\"Photo](\"/assets/images/forest-313f56ef49c00c34156b3a8adb1dead8.jpg\" "\\"New")
\nPhoto by Malene Thyssen - Own work, CC BY-SA 3.0, Link
Project Mycorrhiza is a temporary name to encompass the work relating to what the next generation\nPackit dashboard could look like by seeing how developer time can be saved, minimizing\ncomplexity, reducing context switching, and providing results faster. Research going into this\nwill likely improve Packit overall and even be useful for other related teams. 'Mycorrhiza' means\na symbiotic network between plants and fungi to share nutrients, fats, and sugars between each other to grow.
We will consolidate existing research and begin to interview more teams on what developers are\nmissing the most. Our plan is for this to be done before 2024, likely by December.
Before I explain what Project Mycorrhiza is and what it's about, lets talk about\nthe Packit dashboard and why it's been getting so much love from me the past year.
It's no surprise that Packit is used within a lot of different projects around\nFedora, which includes Convert2RHEL that I'm\na developer of. But I've always felt like Packit's dashboard has missed the mark on\nbeing the go-to for getting an overview for the pipeline, results, or even the\nproject itself.
Since I like making websites better for my own benefit, I've been spending a huge amount of my own\ntime the past year to gradually improve the Packit dashboard to prepare it for something\nbigger. Which is where Project Mycorrhiza comes in.
This is heavily simplified for the purpose of getting a quick overview. I encourage you\nto read more about mycorrhiza on the Wikipedia article about it\nand any related articles!
You might be familiar with something called mycelium, the network of root-like structures that\nfungi form. I'm assuming most of you have seen this form on food before, such as bread\nthat grew mold.
The mycelia helps fungi get nutrients and get enough food to grow mushrooms!\nSome are just terrible to be around, some are interesting to look at but relatively toxic, and\nsome are even edible. Those same labels I applied to the mushrooms are something plants and trees\nsort of do as well!
A mycorrhizal network is a symbiosis between fungi and flowers and trees.\nYou have already seen one too as the photo above is a bunch of Beech trees that\nare \"ectomyccorhizal\"!\nWhat it means is that nutrients are shared between the two, the fungi spreads out mycelia in the soil\nand transfers nutrients to the tree, and the tree provides sugar and fat back to the fungi.
Since my project relates to integrating more services and getting a better\npackaging ecosystem, I chose the name Project Mycorrhiza to put emphasis on the symbiosis between\nthe different tools.
Now with the name explanation out of the way. First and foremost, this should be seen as a kind\nof idea or kind of a temporary working group to see about the future goals of Packit and\nhow the Packit dashboard fits into the Fedora service ecosystem. The Mycorrhiza name itself\nwill only stick around for the duration of this investigation and alignment. Once it is done\nwe will likely drop or change it. 2. Kicks off integration tests through Testing Farm.
There is a lot of packages out there that ships in Fedora, be it through Copr repositories or\nofficial Fedora repositories. For products that ship downstream there is also a downstream\nrelease automation! But what they most have in common is a continuous integration\nworkflow to ensure that they can release whenever they want. Although Packit helps with this\ntremendously, it's only an orchestrator to make the process easier and more automated.
For those that already ship to Fedora, you likely use Copr to do either general releases or just\nto do development builds to test on. Packit can ensure that new commits
Packit can do a whole bunch more than just this and even go into finer granularity, making it\na very powerful service to use when it comes to packaging. However, when it comes to\ndebugging or seeing results of tests. Packit in the current state rarely does anything more than\nproviding links to the results in Copr, Koji, Testing Farm, and so on.
This is where I see the most improvement for consolidating this information. There is so much\nwe could do and I can see so many fun projects given the currently small scope of the Packit\ndashboard. But we need to focus first and foremost on what users want, and although I have\na strong belief I know what would be good, everything mentioned here will need to be followed-up\nwith user interviews and general opinions from users before long-term initiatives will be worked on.
One of the first thing I noticed when I was onboarded to Packit with Convert2RHEL was the lack of\nproject overview. I wanted to see how builds and tests throughout all PRs were doing on the project\nand ideally getting results without having to leave the page. Instead, I found an undeveloped\nproject page, a pipeline view that showed all pipelines, individual result pages with links\nto build logs and test results.
That theme grows abundant throughout the dashboard as well and indicates so much room for\nimprovement.
To reduce the context switching I've experienced throughout it would be great to incorporate\ninformation (and potentially actions) from other services such as Copr and Testing Farm.
In particular, both Copr and Testing Farm provide logs to how things went. We have the potential\nhere to not only include the logs, but improve the workflow through the use of the existing\nPackit pipeline.
We could load logs, parse them for relevant information, follow-build logs (this is dependent on\nthird parties mostly), and even see about providing notifications on the go for when the results\nare in.
Copr has an API that can be utilized for this, and so does Testing Farm, which is how they\nprovide results to their own Testing Farm results page.
Having all of these logs in one section and in particular a unified style would be super\nbeneficial to avoid having to re-parse things.\nLog Detective, a project to help parse logs and provide information on why builds failed, can\nLog Detective, a project to help parse logs and provide information on why builds failed, can\nalso be integrated to help their project get more logs to train with (opt-in of course).
If you manage a product and for instance use Testing Farm you know the pain of waiting for the\nresults to happen. Especially so when you are waiting on test runs within several PRs/MRs.
Getting a better view for the project view to display all the pipelines for the repository\nwould not only help get a holistic view for how things are going, but allow you to instantly\nsee and even be notified of the results.
In the current Packit dashboard you can even see a what's supposed to be search field that\nallows you to search for the forge (like GitHub), git organizations, and git repositories.\nIf you've tried to use this you've quickly realized this needs an exact name and is more of a\n\"quick-link\" to the respective view than a search.
![\"Search-like](\"/assets/images/project-search-6c5794658dcc41ec2d875ff33b6162a2.png\")
What is seen in most other tables throughout as well, including the project view, is that we\ndon't have any filters available. The sorting is also done by most recent first, but what if\nyou want to sort by PR for example? That is missing in the current implementation.
Having a search to get the results quickly would also be good, which would be similar to filter\nbut just a free-form field basically.
So what's next? There is a lot of great information out there already, such as interviews\nby the Red Hat UXD team. We will be going through\ndata reported for the general lacking features developers want or are frustrated with,\nas well as following-up with Packit users with a more Packit-scoped interview to\nsee how on the goal our research is. Depending on this research, which we hope to be done\nbeginning of 2025 in the worst-case scenario, we will start to plan out the work\nto make the Packit service and Packit dashboard be the best it could be.
We will of course continue to improve everything until then, Packit dashboard will get gradual\nimprovements throughout the rest of the year and Packit will continue to work on the goals they've\nannounced for the quarter.
Were you annoyed by Packit creating divergent branches in your package's dist-git repository? You'll be happy to know that Packit now supports a new dist_git_branches syntax that enables fast-forwarding commits between branches.
When defining a propose-downstream or pull-from-upstream job, you can use the new dist_git_branches syntax.
dist_git_branches:
rawhide:
fast_forward_merge_into: [fedora-branched]
epel-9: {}
In this example, Packit runs the downstream synchronization process for the rawhide and epel-9 branches as usual. Additionally, Packit opens a new pull request, reusing the commit from rawhide, for every fedora-branched branch, allowing it to be fast-forwarded when merging.
Do you want to know more? Look at the non-divergent dist-git branches guide
", "url": "https://packit.dev/posts/non-divergent-dist-git-branches", "title": "No more divergent dist-git branches with Packit!", "summary": "Were you annoyed by Packit creating divergent branches in your package's dist-git repository? You'll be happy to know that Packit now supports a new distgitbranches syntax that enables fast-forwarding commits between branches.", "date_modified": "2024-10-28T10:46:18.000Z", "author": { "name": "Maja Massarini", "url": "https://github.com/majamassarini" }, "tags": [ "propose-downstream", "pull-from-upstream", "downstream", "configuration" ] }, { "id": "https://packit.dev/posts/non-git-upstreams-support", "content_html": "We are happy to announce that support for non-git upstreams in the pull_from_upstream job is here!\nThis enhancement simplifies configuration by removing the need to define upstream_project_url,\nopening the door for more use cases, while also simplifying the onboarding in general.
Previously, the upstream_project_url configuration option was required to point to a git repository for the pull_from_upstream job to work.\nNow, with this update, it’s no longer necessary, allowing the job to sync the releases also for packages with non-git upstreams.\nEven for packages having git-based upstreams, this change allows to skip configuration of this option\nwhen the repository interaction is unnecessary.
Without upstream_project_url configured, no repository will be cloned, and no git interaction will occur.\nThe configured actions will be executed in an arbitrary directory.\nAdditionally, related configuration options such as upstream_tag_template, upstream_tag_include, and upstream_tag_exclude will be ignored.\nIf you need to filter releases, this can still be done on the release-monitoring project settings side.
This update also makes automation easier. You can use the packit dist-git init command to generate your configuration\nfile without specifying --upstream-git-url, enabling easier scripting for mass onboarding of your packages.\nFor more advanced use cases, additional arguments can still be added to adjust the configuration as needed.
It’s been a month since two Packit members (Laura and František) attended Flock, the annual Fedora conference, in Rochester. Let’s see some highlights from our journey There and Back Again. Sadly the travel there wasn’t as expected at all, but luckily the tornadoes did not stop us and we both made it to Rochester.
We prepared two talks for the Flock attendees. If you missed it, the recordings are available. But here’s what we presented:
This one mainly targeted the Fedora maintainers and described how you can use Packit for your packages. The basic workflow has been here for some time but we’ve presented a couple of interesting news about what we are currently working on:
The requirement to have a git repository representing is now gone. By NOT specifying the upstream_project_url config option, Packit will not try to clone or interact with the upstream via git. This is especially useful if the upstream project does not use git, or you just don’t need it (e.g. packages using language-specific repositories like PyPI).
If you are interested in having a nice git tree, you’ll welcome that the Packit team is currently working on making it possible to avoid diverging branches when doing release syncing.
Another long-time-awaited feature is support for releasing package groups using side-tags. Since Flock, Nikola from the Packit team polished the functionality and even created a dedicated documentation pagee describing how to use it.
And that’s not all, there are also two related efforts we are in the early phases. One is about using Packit to run reverse-dependency checks/builds. The update is that Mikolaj Izdebski (thanks a lot!) re-enabled a Copr plugin in Koschei so it should now be possible to run the checks independently to Koji which is better for ad-hock CI checks but also to not produce extra load on Koji itself. Ideally, this would be available for both upstream and dist-git pull requests. And speaking of the dist-git pull requests, there is a discussion about the future of Fedora CI and Zuul, we agreed within a team to take a look and see if we can’t help with that. The reasons and questions to answer are covered in the talk.
And that’s still not all. There is also a Google Summer of Code project by Bryan Elee as part of which an integration for OpenBuildService is being implemented. Stay tuned. The CLI support is nearly there.
And lastly, project Myccorhisa. Our effort to create a unified dashboard for various Fedora-related services. Want to help us better understand the needs? Please, describe your usual workflow in this form.
But we were not speaking just about the features but also how we work and how we help people to get on board.
After the talk, there was an interesting discussion. One of the suggestions was to onboard new packages to Packit automatically – we thought about it within a team and will work on opening a pull request with the configuration and most importantly, a description of Packit.
For the second talk, we were joined by Jan Havlín from the Testing Farm team and the main aim of the talk was to show various new and old ways how to use Packit for your project. Rather than showing documentation, we presented the features on real projects and how they configure this so you can easily do the same. You might have seen this style of presentation from us, but don’t be fooled just by the structure, there were a couple of new features presented as well.
One big achievement is a collaboration with Siteshwar Vashisht on integrating OpenScanHub to run static analysis for your projects. The setup is very simple, just set up Packit to run builds both for the pull requests and your main branch and Packit will trigger a differential scan on pull requests for you. We have a separate blog post about this. There is also one written by Situ.
Also, Jan showed how you can newly generate your own Testing Farm tokens using your Fedora account – but when using Packit, this is not needed and Packit will take care of this for you. But maybe you want to use this to play with the Testing Farm environment locally – you can newly reserve a machine thanks to this token.
During the Flock, we’ve quite intensively discussed the possibility of running Packit in Fedora infrastructure. Why? Currently, Packit is run on a RedHat-hosted OpenShift instance, but Packit’s main target is Fedora and we don’t communicate (and also don’t want to) with Red Hat internal services. Also, to show clearly the users that Packit is part of Fedora. On this topic, there was a talk held by David Kirwan about Communishift which is here for users to deploy their projects on Fedora-hosted OpenShift. We can use it, but we discussed with CPE team, that OpenShift managed by CPE team and used for other Fedora infrastructure systems might be a better fit. Matej Focko from our team collected our requirements and we were asked to communicate this publicly via https://discussion.fedoraproject.org.
A lot of interest was caught by the talk about Fedora dist-git forge replacement. Tomáš Hrčka quite nicely covered the current state that his team was asked to do the technical research but did not make any decision. Packit has even been included in their research which we are thankful for. Currently, we have two candidates – Forgejo and GitLab. Both have been deployed for testing purposes and can be accessed via Fedora staging accounts. So far, the Forgejo seems like a better choice both because of extensibility and ease of deployment/maintenance but nothing has been decided yet. There are two Packit-related topics – if Forgejo is picked, we need to implement its support in ogr, our library for git-forge communication, but hopefully, this would be the only place for change, let’s see…;) Another interesting thing is that there is an idea to provide dist-git functionality not directly on the git-forge, but as a separate dashboard/page and this might be worth collaborating as part of the project Myccorhisa.
If you are interested in testing in Fedora, you must watch the talk by Adam Williamson with a long title The hard problems: towards stronger checks on dependencies and compose inputs in Fedora. Hopefully, Packit be a part of the solution covered during the talk.
Thanks to the community aspect of the conference, it was really easy to sit down with anyone and help them with the Packit setup and we’ve managed to onboard a couple of new projects for Fedora automation. Usually, people want to do the onboarding at home, alone (which they hardly do) at first, but they are happy to leave with a working setup after a bit of convincing. We can unblock them more easily, and describe anything needed and they are usually surprised at how simple it is..;)
If you are interested in a talk that was really engaging, take a look at CentOS Stream - a preview of RHEL, a solid base for CentOS SIGs by Adam Šamalík. It was a nice walkthrough covering CentOS Stream and its design and processes. Also, a couple of interesting questions followed.
We also attended the Fedora Infrastructure Hackfest. There were a lot of topics covered, but two had a relation to Packit:
infra-sig and it’s hard to maintain them all. A cleanup is needed (e.g. pass the packages to other relevant parties). For the basic packages, we proposed help with Packit onboarding.There were many more discussions and talks worth mentioning. Feel free to check the schedule with links to YouTube videos from the recording.
Could not make it in person this year? Let’s hope we’ll meet next year. Maybe somewhere in Europe this time. Want to influence the future Flock? There is still a day to fill out the Flock Survey.
", "url": "https://packit.dev/posts/flock_2024_diary", "title": "Packit Flock 2024 Diary", "summary": "It’s been a month since two Packit members (Laura and František) attended Flock, the annual Fedora conference, in Rochester. Let’s see some highlights from our journey There and Back Again. Sadly the travel there wasn’t as expected at all, but luckily the tornadoes did not stop us and we both made it to Rochester.", "date_modified": "2024-09-05T13:16:18.000Z", "author": { "name": "František Lachman", "url": "https://github.com/lachmanfrantisek" }, "tags": [ "fedora", "flock", "conference", "2024" ] }, { "id": "https://packit.dev/posts/openscanhub-prototype", "content_html": "We are excited to announce a new experimental feature in our service: the integration of Static\nApplication Security Testing (SAST) using OpenScanHub.
OpenScanHub is a service that runs various static analyzers on RPM packages - by default Cppcheck,\nShellCheck and the static analyzers embedded in GCC.
Let's have a look at the details of the prototype!
This initiative contributes to the shift left effort, aiming to detect and address security\nvulnerabilities earlier in the development process, thus enhancing overall software quality\nand security. By implementing this scanning functionality for fedora-rawhide, the current\ndevelopment version of Fedora, we aim to catch security issues at the earliest possible stage.\nThis is also important as Fedora serves as an upstream platform for downstream distributions\nlike RHEL, ensuring that any vulnerabilities are addressed before they propagate to these other systems.
The functionality is designed to automatically\nscan for vulnerabilities and issues in code submitted through pull requests.\nIt is controlled using the configuration option\nosh_diff_scan_after_copr_build,\nwhich is currently set to true by default.\nHowever, even with this option enabled, the differential scanning feature in OpenScanHub\nwill only run for users who have also configured Copr builds with the trigger: commit\nsetting and have matching target branches in their pull request and job configurations.\nThis setup is crucial as it allows Packit to access the base build necessary for differential\nscanning, leading to more precise detection of issues introduced by the pull request.
To utilise this feature, you must ensure that Copr builds for commits are configured,\nalong with Copr builds for pull requests, both set to run for fedora-rawhide-x86_64.\nIf you haven't enabled Copr builds for commits yet, you can add the following job\nconfiguration to the jobs section in your Packit configuration:
- job: copr_build
trigger: commit
branch: main
targets:
- fedora-rawhide
preserve_project: true
This configuration assumes that you merge your pull requests into the main branch\nand ensures preserving the Copr project (as opposed to creating a temporary one,\nsee more details here).\nYou can also build in your custom Copr project (more details\nhere).
Here is an example of a scan showing some new findings:
![\"Example](\"/assets/images/openscanhub-findings-f2924a122fc19a512ff6f652bf318ec5.png\")
Besides this newly introduced integration with Packit Service, you can also submit scans locally using Packit CLI,\nsee more details in docs.
As this is an initial prototype, the configuration and functionality may evolve based on user feedback\n(e.g. reporting the actual results of a scan).\nWe invite you to try out this feature and share your thoughts with us\n(e.g. if you would benefit from other osh-cli options to be included).\nFor more information on setting up this feature, see the info above.
A small update. Default configurations for the static analyzers like cppcheck can now be tweaked through --csmock-args CLI option or a csmock_args option in the Packit's config file. For instance, you can specify arguments like --cppcheck-add-flag=--enable=style to check styling issues as seen in this example run triggered from this testing pull-request on Avahi.
Last month, we had the pleasure of engaging with a dynamic audience during our interactive talk on changelogs at the DevConf in Brno, Czech Republic. In case you missed it, you can watch the recording here. Throughout the session, we explored various aspects of changelog usage, including their content, format, and the potential for automation. By asking a series of questions to the attendees, we gathered insights and opinions that highlighted both common practices and divergent viewpoints within the community. In this follow-up article, we aim to summarise the key findings from our discussion, analyse the trends and preferences that emerged, and offer our reflections on the role of changelogs in software development.
![\"foto](\"/assets/images/devconf_changelogs1-eff1b9245492904ddb031a20f181f890.jpg\")
![\"foto](\"/assets/images/devconf_changelogs2-7aedea2abc34a2ce6316feb21a428277.jpg\")
One of the first questions we posed to our audience during the talk was, \"What do you, as a user, like to see in changelogs?\" The most popular elements that the audience showed to like to see in changelogs were breaking changes and new features. Interest in breaking changes indicates that users prioritise being informed about changes that might disrupt their current setup or workflow. As for the features, this shows a strong interest in understanding the latest enhancements and functionalities added to the software. Users appreciate knowing what new capabilities they can leverage. On a similar note, the information about deprecated functionality is also highly valuable for the audience. This can help users plan migrations and avoid using obsolete features. The audience also expressed a clear desire to understand the purpose and context of a new release. Responses such as \"why\", \"purpose\", \"reasons\", \"relations\", and \"changes motivation\" highlight this need. Understanding the rationale behind changes helps users comprehend the development trajectory and decision-making process. Another interesting response was the desire to know \"am I affected\", indicating that users primarily care about whether they need to take action or can safely ignore the update. There was also a response \"not a copy of commit msgs\". But we will get into that later…
The question that followed was, \"What format do you prefer for changelogs?\" The most popular format by far was Markdown. Its simplicity, readability, and widespread use in the developer community make it highly appealing. Markdown's flexibility in formatting and ease of conversion to other formats also contribute to its popularity. This preference may also indicate its frequent use in blog posts or other articles, as Markdown can be easily rendered.
Plain text files were also a prominent choice. We assume this could be for their simplicity and universal compatibility, making them accessible across various platforms and tools.
Other notable formats included ReStructuredText, LaTeX, YAML, and blog posts. These formats cater to specific needs, such as enhanced formatting capabilities, structured data representation, or providing more detailed explanations and context. Several unique and creative preferences also emerged, such as Asciidoc, email, and PDFs. This variety of preferences highlights that the needs of different projects and their users vary significantly.
Following the format, we’ve tried to collect tooling (if any) used by the audience to help with the changelog management. People mentioned various text editors, IDEs and of course, chatgpt/ai. But let’s take a look at one specific tool worth sharing:
From the project’s homepage, towncrier delivers the news which is convenient to those that hear it, not those that write it. During a development, \"news fragments\" (~text files) are created and when there is a new release, one can merge those together. Being user-centric and storing the fragments in git (and being able to review) makes it a really interesting choice worth exploring. Sadly, the pre-commit hooks can’t remind you that you’ve forgotten to add a new news fragment. Luckily, there is help in the form of a Chronographer GitHub application created by Sviatoslav Sydorenko (@webknjaz) (who was by coincidence also present at the talk)
Quite interestingly, 11% of the responders mentioned that no automation is used – there is an opportunity for improvement! (But to be fair, it can also mean that someone from the projects wants to prepare something really useful and do this all by hand.)
There were also some tools like coffee, potato, postal pigeons or beer that we weren’t able to find documentation for. If you find these, let us know so we can add some links...;-)
There were also various git-based solutions suggested which leads us to the next question:
This is a tricky one, right? It might seem like an obvious choice of getting the input for our changelogs. But… yes, there is a “but”. There are two main reasons why one wants to avoid using commit messages for this:
Based on these observations, we came up with the following rules in our team (and talk attendees mentioned the same):
Of course, one can still use commits for this, but we don’t think it’s a good idea to have two goals for one text. If you really want to go this way, there is a Conventional Commits project. If nothing else, it can bring more attention to the commit messages and provide well-defined rules for the project contributors. (Talk attendees also mentioned git-cliff as a changelog generator for Conventional Commits.) You can also use this format independently to user-facing changelog. (Or, maybe as a base info for a human creating the changelog.) To mention also other responses, there were various git-log based solutions mentioned including the functionality provided directly by git-forges.
![\"Conventional](\"/assets/images/conventional_commits-35ef8be2b4387f5212676cac467c6af2.png\")
As a follow-up to the previous questions, we’ve shown a solution we use in Packit. We researched and tried various solutions but this is what finally works for us:
![\"Packit](\"/assets/images/packit_workflow1-35f10086cac60a86bcbb4a80d9addd3f.png\")
If you forget, a GitHub action will mark the PR red to remind you. (You can also put “N/A” if there is no user-facing change and the PR should be skipped for this check.)
There is a GitHub action that we manually trigger when a new release should be prepared – as a result, new pull request is created with the aggregated changelog and version being updated.\nWhen this pull request is merged, the content of the changelog is also put into GitHub release description and from that taken when preparing downstream (i.e. Fedora) updates
![\"Packit](\"/assets/images/packit_workflow2-8bf805ef977f91ba63dcf92ef71715b4.png\")
\n![\"Packit](\"/assets/images/packit_workflow3-7beb93a0fe0d14db1816c880e0bc802b.png\")
\n![\"Packit](\"/assets/images/packit_workflow4-c0745cfcdcae87a4c5c7132b9926ff74.png\")
![\"Packit](\"/assets/images/packit_workflow5-dddf27668b755420ae946f0459e0f3e6.png\")
Important bit is that in both ways the changelog snippets are used, there is a review in place. So, you can still revisit the text, combine more entries together or remove if this is not relevant to the user after all.
You can, but don’t need to use the same, but try to think about this, have a discussion within a team. The discussion itself can help you think more about your users.
Thanks to our fellow attendees, we can share some examples to be inspired by:
In addition to preferences, we also sought feedback on potential improvements for managing changelogs. The responses highlighted several key areas where the audience sees opportunities for enhancement:
Several responses addressed specific needs, such as differentiating upstream and downstream changelogs, supporting all CI systems, and referencing the tickets associated with changes. Additionally, there were responses emphasizing the importance of keeping changelogs simple and easy to understand.
And now what?
What you can do now? Improve changelog in your project. Get involved in the project you like and help with the changelogs. Read the changelos.
What we can do together? Let’s collaborate on the tools and share good practices!
And what about the standardisation? Let’s create a new standard! https://xkcd.com/927/
With that, let’s quote a response from one of our attendees:\n\"Many more people read the changelog than write it, so it's worth it to put in the effort.\"
This post was also posted at medium.com.
", "url": "https://packit.dev/posts/changelogs", "title": "Do you like your changelogs? What DevConf.CZ attendees think", "summary": "Last month, we had the pleasure of engaging with a dynamic audience during our interactive talk on changelogs at the DevConf in Brno, Czech Republic. In case you missed it, you can watch the recording here. Throughout the session, we explored various aspects of changelog usage, including their content, format, and the potential for automation. By asking a series of questions to the attendees, we gathered insights and opinions that highlighted both common practices and divergent viewpoints within the community. In this follow-up article, we aim to summarise the key findings from our discussion, analyse the trends and preferences that emerged, and offer our reflections on the role of changelogs in software development.", "date_modified": "2024-07-01T00:00:00.000Z", "author": { "name": "František Lachman", "url": "https://github.com/lachmanfrantisek" }, "tags": [] }, { "id": "https://packit.dev/posts/devconf-2024", "content_html": "The first part of June is usually quite busy for our team. Why? The last couple of years, this has been a time of DevConf.CZ conference. (The unpredictable January had been changed into a more pleasant June.)\nEven though the conference itself is important, it’s used as an opportunity for various people from around the globe to come to Brno and thanks to that, a lot is happening also during the days around.\nFor the Packit team, it’s a nice opportunity to have the whole team together in one place – we can do some fun teambuilding (like canoeing this year) but also discuss any technical topics or meet our users and realise how are the real people behind all the nicknames. This time we also prepared something for them:
![\"Packit](\"/assets/images/team_at_devconf-afb9591ce65a7eec16d0cd6b938dc91f.jpg\")
Before DevConf, we recognized a unique opportunity: numerous users and potential users of Packit would be visiting Brno for the conference. Therefore, we decided to organise an in-person workshop with a main focus on our release automation. We had previously organised multiple online runs, for which you can find the materials here, so we were mostly prepared. This initiative brought both Red Hatters and non-Red Hatters, resulting in a rich exchange of ideas and great feedback. In the end, the workshop served not only for learning about our release automation but also about the CI capabilities of Packit in upstream.
During the workshop, several key areas of interest emerged:\nBuilding in Sidetags - There was significant interest in building in sidetags. Participants provided valuable feedback on the workflow and configuration that Nikola Forro is currently developing, see the GitHub issue. One of the discussion points was the automatic resolution of dependencies as the next step for the current static configuration.\nCommon specfile manipulation tasks - Participants expressed a need for ways to handle common specfile manipulation tasks, which could be utilised in Packit's actions or for debugging purposes. Specific use cases included removing source/patch ranges for Copr builds, replacing sources within specfiles or getting and setting specfile versions. Our specfile library already covers some of these, but besides that, also other alternative solutions were proposed, such as creating a CLI specifically for handling these tasks or adding Packit subcommands to facilitate these operations.
Besides those, in relation to the release automation, some existing issues were brought up, such as the one about Packit to not create divergent branches when syncing release. Additionally, a bug/inconsistency was directly addressed and fixed during the workshop, see https://github.com/packit/packit/pull/2327 .
Overall, the workshop was a success and we are happy for our great users for coming! The gained insights will definitely influence the ongoing development and improvement of Packit. We celebrated the successful workshop with a nice lunch together with the participants.
Of all the various proposals prepared by our team (and there as a lot!), 3 were accepted and we were able to show some interesting topics to the audience.
![\"Laura](\"/assets/images/laura_franta_presenting-ee59e9798e209dc044ce54f8c420fffe.jpg\")
The first session was an interactive on hold by Laura and František about changelogs – we used a Mentimer platform to be able to interact with the audience. We could not only collect information what people are interested to see in changelogs or what tooling do they use, but also showed charts from the research Laura made as part of here diploma thesis the last year. As part of the session, we were able to show the changelog automation we use in Packit. There is also a blog post covering the talk and all the interesting findings.
For the next session, František took a bunch of happy (of course..) Packit users and organised a user showcase. In just half an hour 8 people went to stage and provided an introduction to Packit, tmt, Testing Farm and showed 4 interesting usecases. Recording can be found here. Interestingly, the two of the usecases overlayed – Cockpit has introduced their tests-cases into their dependencies to realise issues soon and one of such dependencies is Podman. Both Podman and Cockpit was presented on the stage.
During the third session, Laura and Tomáš showed our journey to team role rotation and how we do this these days. They used Mentimer as well as for the changelog one so it was a great fun. Missed it? No worries, there is no only a recording, but also a blog-post serie covering this topic. The last part helps you do the same, and as usual, we have this automated…
![\"Laura](\"/assets/images/laura_and_tomas_presenting-6ab4883c30d4bd9790065a7d139b388f.jpg\")
Even though some of our talk proposals were not accepted this year, our users represented us very well. In addition to the previously mentioned user showcase), there were two other dedicated talks by Packit users:
Additionally, Siteshwar Vashisht presented about OpenScanHub, a service for static analysis of Linux distributions, where he also mentioned Packit and our plans for integration (https://pretalx.com/devconf-cz-2024/talk/7C38GJ/).
So, that was it. A DevConf week we enjoy being part of same as enjoying it being over.
![\"Team](\"/assets/images/team_booth-f1e93b6716011b1243e6b6d2251432c5.jpg\")
Have you ever wanted to bring your pull request changes in a cloud image easily?\nCurious about how easy it can be? With Packit, it can be just about commenting on your pull request with /packit vm-image-build.
With the above command, Packit automates all the manual steps needed to create an\nRPM package with your pull request changes and asks the Image Builder to install it\ninside a brand new cloud image.\nLet's have a look at the prerequisites for this.
If you don't already have a business account you can create a\nRed Hat Developer account at no cost here.
You need a subscription in order to use the\nImage Builder service\nand launch the builded images in the AWS management console.
Before uploading an AWS AMI image, you must configure the AWS system for receiving them.
Follow these steps\nto satisfy the above prerequisites.
Are you wondering what are the manual steps for bringing your pull request changes\nin a cloud image and why you should automate them?
There could be many ways to achieve this goal but let's see together the closest to our\nautomated solution. Below you can find a summary of all the needed manual steps;\nI am quite sure after reading them, you will want to automate them with Packit!
Build an RPM package with your pull request changes through COPR, go to https://copr.fedorainfracloud.org
copr-cli.copr-cli.Create a new cloud image through the Image Builder console, go to https://console.redhat.com/insights/image-builder\n7. Login with your Red Hat developer account.\n8. Click on the Create Image button, choose AWS image type and follow the wizard.\n9. WAIT for the build to finish.\n10. Open the Launch link for the builded image.
Launch and access the AWS image through the AWS management console, go to https://aws.amazon.com/console/\n11. The previous link will open an AWS console tab with the\nLaunch an Instance wizard preset to use the builded image.\nYou need to login into the AWS management console using an AWS Account ID\nallowed to access the AMI Image you just created.\n12. Select a Key pair, or create one if you don't have it already,\nto be able to ssh the image later.\n13. Click on Launch Instance\n14. Connect to instance using an ssh client\n15. Add the previously created COPR repo to the list of available dnf repositories.\n16. Install the package you have created at step number 4.\n17. Now you are ready to test your code in a real cloud image.
For every new pull request you want to test directly in a cloud image you have to repeat\nsteps 4-16 or automate them through Packit!
Installing Packit is pretty straightforward.
Now you are ready to automate the process as described below.
Create a .packit.yaml configuration file in your pull request.
But just the first time! After your pull request has been merged, Packit will take the .packit.yaml file from the target main branch.
The configuration file will look like the following:
---
jobs:
- job: copr_build
trigger: pull_request
targets:
- fedora-all
- job: vm_image_build
trigger: pull_request
image_request:
architecture: x86_64
image_type: aws
upload_request:
type: aws
options:
share_with_accounts:
- < shared-aws-account-id >
image_distribution: fedora-39
copr_chroot: fedora-39-x86_64
image_customizations:
packages: [hello-world]
The first job tells Packit service to build an RPM package, for the Fedora release you want,\nin this example all the active fedora releases, and to add your pull request changes to the package.
To further customize the COPR builds made by Packit you may want to give a look at this\nguide.
The second job tells Packit how to configure the Builder Image service.
The first two lines of this job are still meant for Packit;\nthey allow Packit to react to your pull request comment /packit vm-image-build.\nPackit does not build a VM image automatically, as it does when it builds a COPR package,\nto save you from no wanted costs.
- job: vm_image_build
trigger: pull_request
The other lines are meant to customize the Image Builder behaviour.
You are asking to build an AWS image, with a fedora-39 distribution,\nfor the x86_64 architecture and you want to share it with the listed\nAWS Account IDs.
image_request:
architecture: x86_64
image_type: aws
upload_request:
type: aws
options:
share_with_accounts:
- < shared-aws-account-id >
image_distribution: fedora-39
You don't want to manually install the COPR package into the image,\nfor this reason you ask the Image Builder to install it (hello-world).
You tell Image Builder to take it from the COPR chroot fedora-39-x86_64,\nand you don't need to create or specify a COPR project because it has\nbeen automatically created by Packit for you.
copr_chroot: fedora-39-x86_64
image_customizations:
packages: [hello-world]
Create a pull request, mine will show you the world word in green 🌿.
You are ready to go, just comment your pull request with
/packit vm-image-build
and the image will be built and customized for you.
Look for the check named vm-image-build-fedora-39-x86_64\nand wait for it to finish.
![\"Wait](\"/assets/images/checks_vm_image_build-0ec652132670f4da590dca9dc372a468.png\")
Open its details and you will find the link\nto the AWS image.
![\"The](\"/assets/images/link_to_aws_image-16f87362483365f8530c80041de39ada.png\")
Open the AWS link (you need to be already logged in) and\nsee the details of your image ready to be launched.
![\"The](\"/assets/images/ami-link-2bb9d9e9a1da6c8e18ca31b39db13789.png\")
Launch your image instance and connect to it.
![\"Connect](\"/assets/images/connect-to-instance-0f2ae4856b17566477e3e4e29074075f.png\")
Test it!
![\"Test](\"/assets/images/hello-world-809c7da500a4aca0a1d5b7fbdd3ea1fc.png\")
Have you ever wanted to make changes in an RPM spec file programmatically? specfile library\nhas been created for that very purpose. It is a pure Python library that allows you to conveniently\nedit different parts of a spec file while doing its best to keep the resulting changeset minimal\n(no unnecessary whitespace changes etc.).
The library is packaged for Fedora, EPEL 9 and EPEL 8 and you can simply install it with dnf:
dnf install python3-specfile
On other systems, you can use pip (just note that it requires RPM Python bindings to be installed):
pip install specfile
Let's have a look at a few simple examples of how to use the library.
To bump release and add a new changelog entry, we could use the following code:
from specfile import Specfile
with Specfile(\"example.spec\") as spec:
spec.release = str(int(spec.expanded_release) + 1)
spec.add_changelog_entry(\"- Bumped release for test purposes\")
Let's take a look at what happens here:
We instantiate Specfile class with a path to our spec file and use it as a context manager\nto automatically save all changes upon exiting the context.
We then use expanded_release property to get the current value of Release tag after macro expansion.\nWe assume it is numeric, so we simply convert it to integer, add 1, convert the result back to string\nand assign the new value to release property.
Note that release/expanded_release properties exclude dist tag (usually %{?dist}) - for convenience,\nit is ignored when reading and preserved unmodified when writing. If that's not what you want, you can use\nraw_release/expanded_raw_release properties instead.
Finally, we add a new changelog entry. We don't specify any other arguments but content,\nso the author is determined automatically using the same procedure as rpmdev-packager uses\nand date is set to current day.
%autochangelogTo make a switch from traditional changelog to %autochangelog, we could do the following:
import pathlib
from specfile import Specfile
spec = Specfile(\"example.spec\", autosave=True)
with spec.sections() as sections:
entries = sections.changelog[:]
sections.changelog[:] = [\"%autochangelog\"]
pathlib.Path(\"changelog\").write_text(\"\\n\".join(entries) + \"\\n\")
Let's take a look at what happens here:
We instantiate Specfile class with a path to our spec file and we also set autosave argument\nthat ensures that any changes are saved automatically as soon as possible.
specfile heavily relies on context managers. Here we are using sections() method that returns\na context manager that we can use to manipulate spec file sections. Upon exiting the context,\nany modifications done are propagated to the internal representation stored in our Specfile instance,\nand since autosave is set, they are immediately saved to the spec file as well.
First, we store a copy of the content of the %changelog section. The content is represented\nas a list of lines.
Then we replace the content with a single line - \"%autochangelog\".
Finally, we save the stored content into a \"changelog\" file.
Contexts can be nested. Here is a code that iterates through all package sections\n(including the first, implicitly named one; also known as preamble) and prints expanded value\nof all Requires tags:
spec = Specfile(\"example.spec\")
with spec.sections() as sections:
for section in sections:
# normalized name of a section is lowercased
if section.normalized_name != \"package\":
continue
with spec.tags(section) as tags:
for tag in tags:
# normalized name of a tag is capitalized
if tag.normalized_name != \"Requires\":
continue
print(f\"Section: {section.id}, Tag: {tag.name}, Value: {tag.expanded_value}\")
Let's take a look at what happens here:
We instantiate Specfile class with a path to our spec file. This time we don't set autosave because\nwe are not doing any modifications (though we could still save any changes explicitly using save() method).
Then we use sections() context manager and iterate through sections; we skip sections not called \"package\"\n(the initial % is ommited for convenience).
After that we use tags() context manager and pass the current section as an argument. This allows us\nto iterate through tags in the current section. Without any argument, we would get a list of tags in preamble,\nthe very first section in a spec file. We skip tags not called \"Requires\" and finally print the values\nof Requires tags after macro expansion. We also print tag names (not normalized) and section IDs - those are\nsection names followed by options, e.g. \"package -n alternative-name-for-example\".
Are you interested in more details, trying the library out or even contributing? You can find specfile source code on GitHub.\nSee the README for more tips and usage examples.\nYou can also check out the API reference.
", "url": "https://packit.dev/posts/specfile-introduction", "title": "Introduction to specfile library", "summary": "Have you ever wanted to make changes in an RPM spec file programmatically? specfile library", "date_modified": "2024-01-12T00:00:00.000Z", "author": { "name": "Nikola Forró", "url": "https://github.com/nforro" }, "tags": [ "specfile" ] }, { "id": "https://packit.dev/posts/experiences_with_rust", "content_html": "\"How absurdly simple!\" I cried.
\"Quite so!\" said he, a little nettled. \"Every problem becomes very childish when once it is explained to you.\"
We have planned for a while to use Packit to generate packages on Copr\non demand for our somewhat complicated Rust executable, stratisd. It\nlooked like this was going to be challenging, and in a sense it was,\nbut once the task was completed, it turned out to have been pretty\nstraightforward.
The two primary parts of our Stratis project are stratisd, a big,\nfairly complicated Rust project which generates multiple distinct Rust\nexecutables and also installs scripts and configuration files and so\nforth, and stratis-cli, a relatively simple Python project which\ncommunicates with stratisd over the D-Bus. Our main purpose in getting\non-demand packages of both these projects was not to test the\npackaging, although that is a nice thing to do, but to have a\nconvenient way to do functional testing of the project, frequently\ngenerating a stratisd package from one stratisd pull request and a\nstratis-cli package from a matching stratis-cli pull request.
The Packit team had already obliged us by preparing a Packit\nconfiguration file for our stratis-cli repo, we thus merely had to\nfigure out how to do the same for stratisd. We already had some\nscripts which we could run by hand to make the SRPMs for both projects\nso that we could manually send them to Copr so, as it turned out, all\nwe really needed to do was figure out how to write a Packit\nconfiguration file for stratisd so that Packit would do these tasks\nfor us. There follows a quick summary of the decisions we made to\nsolve this problem. Note that our whole and only task was to figure\nout how to create the source artifacts and edit the spec file and\nto provide these in such a way that Packit could take over from there,\nbuild the SRPM, and carry on to request the Copr builds which provide\nthe binary packages for testing.
A Packit configuration is used to set certain configuration options,\nto override certain actions, or to define certain hooks. The\navailable actions and hooks are specific to a given job or set of jobs.\nIf an action is not\noverridden in a project's Packit configuration, Packit will execute\nits own default action. For example, Packit's default for the\ncreate-archive action is just git-archive. Any action can be overridden by\nspecifying a sequence of commands. For the stratisd Packit\nconfiguration, we found that we had to override the majority of the\nactions.
Note that the stratisd Packit configuration file is quite\nsimple as most of the action is in the create_archive.py script. Some\nthings to make note of are the following:
merge_pr_in_ci is set to false. This prevents Packit from\nautomatically merging our pull request into its target branch. It has\nalways been our custom to build from the unmerged branch when testing\nPRs and we preferred to do the same in our Packit configuration.
fix-spec-file contains a dummy echo action. This is how we override\nPackit's default spec file editing action. Instead of specifying an\noverride for this action, we use our own script, create_artifacts.py, to\nedit the spec file as well as to generate the three source artifacts that we\nuse in this package in the create-archive action.
create_artifacts.py uses the Packit team's specfile package to\nedit the stratisd specfile. We needed just two modifications: 1. To overwrite the Version field with our preferred version string. 2. To overwrite the Source entries with the names and paths of the\nsource artifacts.\nThis requires just one very simple function using specfile.
In the Packit configuration, the update_release field is set to\nfalse. We prefer to update the Version field in the spec file using\nour create_archive.py script, so that the updated version is\nrecognized as a pre-release version of our current version by\nrpmdev-vercmp.
We modified our stratis-cli Packit configuration file to work the\nsame way as our stratisd one.
In summary, we got the ability to take advantage of the Packit\ninfrastructure for Copr builds by figuring out how to satisfy its\nrequirements for the source artifacts and the specfile. Note that our\ndecisions about how to do this were made based on the scripts we had\nalready written to generate the SRPMs and the particular requirements\nof our project. For example, our release scripts are written in\nPython, and we stuck with that choice. That turned out to be handy,\nbecause that allowed us to use the specfile project in our scripts to\nedit the spec file. But it would have been possible to write the\nartifact creation script in Rust using the cargo xtask pattern just as\nwell, and to solve the spec file rewriting problem using, e.g., sed.\nWe overwrote the Version field in the spec file, rather than allowing\nPackit to autobump our release number, because our development process\nrequires us to bump the version in the Cargo.toml (for Rust) and\nsetup.cfg (for Python) files to the version we will release as soon as\nwe begin development. These choices and their implementations could be\nmade differently to support a project with different constraints and\ndifferent existing infrastructure.
", "url": "https://packit.dev/posts/experiences_with_rust", "title": "Experiences using Packit for a Rust executable Project", "summary": "\"How absurdly simple!\" I cried.", "date_modified": "2023-10-10T00:00:00.000Z", "author": { "name": "mulhern", "url": "https://github.com/mulkieran" }, "tags": [] }, { "id": "https://packit.dev/posts/verify-sync-release-volunteers", "content_html": "In the upcoming months, we plan to migrate our service to a new cluster. However, this may affect propose_downstream\nand pull_from_upstream jobs due to the new firewall rules. The problematic aspects could be:
actions during syncing the release involving interactions with external serversTo smoothen this transition, we kindly encourage you to enable one of these jobs on our already migrated staging instance.\nThis recommendation is particularly important if you belong to one of the groups affected by the two previous points.\nThis proactive step will help us identify and address any issues promptly.
Both instances can be run at the same time and the behaviour can be configured via the packit_instances configuration key,\nwhich is by default set to [\"prod\"]. Picking just one instance is required only for koji_build and bodhi_update jobs since\nboth instances work with the production instances of Fedora systems. To avoid too much noise in your dist-git PRs, you\nmay enable the pull_from_upstream/propose_downstream job for only one target, resulting in only one additional PR created.
Here's how you can enable one of the jobs on the staging instance:
pull-from-upstream:\nThe only thing needed is to duplicate the job in your Packit config using packit_instances configuration option. Example:- job: pull_from_upstream
trigger: release
packit_instances: [\"stg\"]
dist_git_branches:
- fedora-rawhide
propose-downstream:\nFor this job, you first need to enable our staging Github app\n(you should be already automatically approved if you had been previously approved for production instance).\nAfter that, similarly to pull-from-upstream, you only need to duplicate the job in your Packit config using packit_instances. Example:- job: propose_downstream
trigger: release
packit_instances: [\"stg\"]
dist_git_branches:
- fedora-rawhide
When merging the PRs created by Packit, please don't forget to merge the PRs created by the production instance\nif you have a follow-up koji_build job enabled to ensure your builds will not be skipped\n(or you can allow builds for staging instance as well, see allowed_pr_authors)).
We would be happy if you could then report any problems to us. We appreciate your collaboration in ensuring a seamless migration. Your Packit team!
", "url": "https://packit.dev/posts/verify-sync-release-volunteers", "title": "Call for volunteers: help to test us the release syncing using staging instance", "summary": "In the upcoming months, we plan to migrate our service to a new cluster. However, this may affect propose_downstream", "date_modified": "2023-09-05T12:46:18.000Z", "author": { "name": "Laura Barcziová", "url": "https://github.com/lbarcziova" }, "tags": [ "downstream", "pull-from-upstream", "propose-downstream", "staging" ] }, { "id": "https://packit.dev/posts/manual-triggering", "content_html": "Recently, we received multiple contributions from the Strimzi team, specifically Jakub Stejskal\nand David Kornel,\nfor the functionality of manual triggering of jobs and other related improvements, mostly focusing on the testing\nUX. We are very happy about these and would like to showcase the results of their awesome contributions.
Strimzi team wanted to onboard Packit to ease their testing in pull requests, but they have had multiple test suites that could run\nfor a long time, and they did not want to run all of the test suites for each new commit in a pull request.
Let's now look together at what they implemented to solve their usecase.
Firstly, a new configuration option manual_trigger was introduced.\nWith this new configuration option, users can enable triggering Packit jobs only manually and avoid specified jobs being\nautomatically triggered when, e.g., a new commit arrives to a pull request.\nThe only thing needed to make this work is to add manual_trigger: true to the job's definition:
- job: tests
trigger: pull_request
targets:
- centos-stream-9-x86_64
skip_build: true
manual_trigger: true
This new configuration option allows saving resources and running builds or tests, e.g. only when the pull request is ready for\ntesting and can be especially useful for projects having huge test plans.
The above solution is very easy to use; however, there might be use cases where the users don’t want to trigger all the jobs.\nA particular example could be running a smoke test job before running the sanity one.
To solve this, for the test jobs, Jakub and David introduced 2 new ways to trigger a specific job.
The first one is to trigger the job based on the configured identifier. To trigger a test job with identifier: regression-operators in the\njob configuration, the Packit comment command will be:
/packit test --identifier regression-operators
That command will execute the job with this specific identifier, nothing else.
And what if someone wants to execute more than one job? Users can easily use multiple identifiers in a comma-separated list:
/packit test --identifier regression-operators,regression-components
But specifying a longer list of identifiers every time might get a little bit annoying,\nespecially when the identifiers are usually used together repeatedly.
To improve the UX, there was introduced labels configuration field that can group together multiple jobs.\nEach job can contain a list of labels in their definition:
- job: tests
trigger: pull_request
identifier: regression-operators
targets:
- centos-stream-9-x86_64
skip_build: true
manual_trigger: true
labels:
- regression
- sanity
- job: tests
trigger: pull_request
identifier: regression-components
targets:
- centos-stream-9-x86_64
skip_build: true
manual_trigger: true
labels:
- regression
- job: tests
trigger: pull_request
identifier: acceptance-operators
targets:
- centos-stream-9-x86_64
skip_build: true
manual_trigger: true
labels:
- acceptance
- sanity
With this, one can comment
/packit test --labels regression
and the comment will trigger all jobs that contain regression in the list of labels in the job configuration.\nIt is again also possible to specify a comma-separated list of labels:
/packit test --labels regression,sanity
As already mentioned, these improvements were made as contributions from outside of the Packit team, and it was such\na nice experience to collaborate with someone new! And this brings us to a reminder:\nAnyone can contribute! So if you are missing some features, feel free to open a pull request, and we will gladly help\nyou so that your feature can land in our production!
", "url": "https://packit.dev/posts/manual-triggering", "title": "(Tests) job triggering improvements", "summary": "Recently, we received multiple contributions from the Strimzi team, specifically Jakub Stejskal", "date_modified": "2023-07-11T06:46:18.000Z", "author": { "name": "Laura Barcziová", "url": "https://github.com/lbarcziova" }, "tags": [ "configuration" ] }, { "id": "https://packit.dev/posts/monorepos", "content_html": "We are very happy to announce a major enhancement to Packit! We have now added support for\nmonorepositories, enabling the integration of upstream repositories containing multiple downstream packages.\nIf you have a repository in the monorepo format, Packit can now help you automate the integration to downstream\ndistributions both from CLI and as a service.
Let's take a look at how a monorepository should be configured so that Packit can automate the process!
The main addition to the Packit configuration file in the context of monorepositories are the keys\npackages and paths.
packages holds a dictionary of {package_name: package_configuration} where package configuration can contain any keys\nthat were previously used as top-level keys for the standard (single) package configuration. The paths can be defined\nin each package_configuration and should hold a list of paths that should be considered for the particular package.
The packages section in the configuration can then look like this:
packages:
python-copr:
downstream_package_name: python-copr
upstream_package_name: copr
paths:
- ./python
specfile_path: python-copr.spec
files_to_sync:
- python-copr.spec
copr-cli:
downstream_package_name: copr-cli
upstream_package_name: copr-cli
paths:
- ./cli
specfile_path: copr-cli.spec
files_to_sync:
- copr-cli.spec
copr-backend:
downstream_package_name: copr-backend
upstream_package_name: copr-backend
paths:
- ./backend
specfile_path: copr-backend.spec
files_to_sync:
- copr-backend.spec
That was the configuration of the packages and their locations in general, but how should these values then be utilised?
For the Packit Service jobs, there is one more addition to the configuration: the packages key again,\nthat can be used in each job and tells which packages should be considered for that particular job.
As a result, the repository in monorepo format could have jobs in the Packit configuration configured like this:
jobs:
- job: copr_build
packages:
- copr-backend
- copr-cli
trigger: pull_request
targets:
- fedora-all-x86_64
preserve_project: True
- job: copr_build
packages:
- python-copr
trigger: pull_request
targets:
- fedora-all-x86_64
- fedora-all-aarch64
manual_trigger: True
And the commit statuses in GitHub/GitLab will also include the name of the package:\n![\"Monorepo](\"/assets/images/statuses-8048b69ec99393dd77aaace7258dffff.png\")
As for the CLI, you can now for each command specify the -p or --packages argument followed by the package name\nand the scope of the command will take into consideration only the specified packages:
packit build in-mock --package my-package-1 --package my-package-2
If you have a repository in the monorepo format, give it a try now and share your feedback with us!
Going forward, we are about to implement the possibility of defining dependencies between jobs,\nallowing for even greater flexibility and control of monorepository jobs.
We are also happy to help with any contributions from the community to help us expand and refine the support with additional functionalities,\nsuch as being able to define paths the service should react to\nor templating features.
", "url": "https://packit.dev/posts/monorepos", "title": "Introducing monorepository support", "summary": "We are very happy to announce a major enhancement to Packit! We have now added support for", "date_modified": "2023-07-04T07:20:06.000Z", "author": { "name": "Laura Barcziová", "url": "https://github.com/lbarcziova" }, "tags": [ "monorepos" ] }, { "id": "https://packit.dev/posts/release-field-handling", "content_html": "We have recently made some fixes to the process of handling the Release field regarding the %autorelease macro, so let's take that opportunity to explain how it works.
You can maintain the Release field manually, you can use a dummy value or you can take advantage of the %autorelease macro.
Release manuallyYou can maintain the Release field manually as you would do downstream, for example you could bump the value every time you make changes to the spec file and reset it to 1 when you release a new version.
Packit will not touch the value unless it detects a change in Version and no change in Release. In such case it will reset Release to 1 in the dist-git spec file, to ensure that the resulting NVR is not higher than any existing NVR in dist-git (that could have been already created by propose_downstream in a different branch for example).
You most likely want to enable the sync_changelog option so that your upstream %changelog is synchronized to dist-git as well.
You can use a value like 0 or 1 and never touch it, Packit will make sure it is set to 1 in the dist-git spec file.\nYou can do this if you don't care about upstream %changelog, i.e. you have sync_changelog disabled and use copy_upstream_release_description or the changelog-entry action to generate it downstream.
%autoreleaseYou can use the %autorelease macro in the Release field and the %autochangelog macro in %changelog. In this case Packit will not change anything, it will only synchronize changes made to the arguments of the macro (if any).
If you want to start using %autorelease and %autochangelog, you should do the change in dist-git before releasing a new version upstream and triggering propose_downstream job, otherwise Packit will continue to set Release to 1 in the dist-git spec file.
%autorelease in dist-gitNo matter how you maintain the Release field in your upstream spec file, Packit will never overwrite the %autorelease macro if it is used in the dist-git spec file.
pre-commit is a wonderful tool that saves you\na lot of time by automatically checking your changes before you\ncommit and/or push them out.
For example, in our packit repo\nwe run various hooks upon each commit:
We also have a few hooks\nwhich we've created and which you might find useful as well.
We in Packit love linear git history.\nThis hook checks whether your branch is up-to-date with the upstream,\nand we use it to know when it's time to rebase changes before we push them.
To try, add this to your .pre-commit-config.yaml
- repo: https://github.com/packit/pre-commit-hooks
rev: v1.2.0
hooks:
- id: check-rebase
args: [upstream_url]
Packit uses a YAML configuration file\nin an upstream repository.\nWe have a packit config validate command\nto check it, but it's easy to forget (to run it) and notice a typo after you\ncommitted and pushed the changes and waited for some time for Packit to tell you\nthat in a PR.
It's much faster to catch the problem before committing and/or pushing the changes.
This hook runs (only if there's been a change in the .packit.yaml)\npackit in a container (from our image),\nmounts your sources inside and runs the packit config validate.
- repo: https://github.com/packit/pre-commit-hooks
rev: v1.2.0
hooks:
- id: validate-config-in-container
It requires docker/podman, which can be a problem for example in a\nCI.
Another option is a hook which runs the packit binary directly installed\non the machine. If there's no packit, the hook passes to not break\nfor example your CI where packit is most likely not installed.
- repo: https://github.com/packit/pre-commit-hooks
rev: v1.2.0
hooks:
- id: validate-config
packit itself?Right, typically, when you run a pre-commit hook for the first time,\nit installs everything it needs.\nLike in case of Python, pre-commit pip installs all the dependencies.
The problem in our case is that packit has a lot of dependencies and\nsome of them (if missing) are compiled from source when you try to\npip install packit.\nThat needs gcc and additional devel packages\nto be installed on the machine prior to running the hook for the first time.\nThat would make the hook usage very user unfriendly, leaving aside that\nsometimes (in a CI) you don't have access to the machine to install them\nprior to running the hooks.
As you will see in the following paragraphs, the year 2022 was really fruitful for the Packit project. Without further ado, let’s take a look at what the Packit team accomplished last year!
We have made a huge improvement in downstream automation. At the beginning of the year, we finished the workflow and you are now able to use Packit to get your release from upstream via dist-git and Koji to Bodhi. As usual, you can pick just what you need. This workflow consists of three jobs:
propose-downstream: as a reaction to an upstream release, the source archive is saved to a lookaside cache, specfile is updated and sent as a pull request to Fedora dist-git.koji-build: as a reaction to a new dist-git commit, a new Koji build is triggered (you can specify allowed authors of a commit or merged pull request).bodhi-update: as a reaction to a successfully finished Koji build, a new Bodhi update is created![\"Detail](\"/assets/images/bodhi-update-b24d047f5572831c4ad8de446cf81148.png\")
But that wasn’t all. At the very end of the year, the Packit team implemented an alternative to the propose-downstream job that we call pull-from-upstream. The logic of the job is the very same: the source archive is saved to a lookaside cache, specfile is updated and sent as a pull request to Fedora dist-git. The only – and main – difference is that the job is defined downstream (in the default dist-git branch, rawhide or its main alias) so you don’t need to install Packit in the upstream repository. The information about a new release is received from the Upstream Release Monitoring. The pull-from-upstream job is mainly targeted to the Fedora maintainers without upstream access or with upstream not being supported by Packit. (This job works with any upstream using git.) The setup is nicely described in this blog post. And if you want a dedicated documentation page for the Fedora downstream automation, look at https://packit.dev/docs/fedora-releases-guide/.
![\"Pull](\"/assets/images/pull-from-upstream-75eca73c81b62ad029f0c029f0b4e557.png\")
And that’s still not all, we’ve also added propose-downstream to our dashboard. You can now the jobs in the Pipelines view. Also, logs can be checked on a detail page (that can be accessed from a status of a release commit).
![\"Propose](\"/assets/images/propose-downstream-result-page-a2d517abb0153c630f4f03b2ad8ccda5.png\")
Still not convinced we’ve done a lot? When using various downstream jobs, you can still hit an issue now and then. (Messages from Fedora infrastructure can get lost or some intermittent error can occur.) Packit automatically retries to overcome temporary issues, but sometimes it’s not enough or there is a real problem that needs to be fixed elsewhere. We can’t resolve the real problems for you, but we can help let you retry the job when needed. And you have two places where to do that.
As you might be used to with the propose-downstream job, you can use comments in an upstream issue to retrigger Bodhi updates and Koji builds as well. Just configure issue_repository so Packit knows where to create issues in case of problems. (This does not need to be an upstream issue and this repository can be used for multiple projects.) Alternatively, if you use dist-git pull requests (either made by Packit or other maintainers), you can use a pull request comment to retrigger Koji Build or Bodhi update.
![\"Comment](\"/assets/images/dist-git-pull-request-comment-61dc300ce80bfec8c7ec5dd2baf20c92.png\")
If you are interested in what Packit has done for its users, you can take a look at the activity of the packit (or packit-stg) FAS user in dist-git, Koji or Bodhi.
![\"Dist-git](\"/assets/images/packit-dist-git-activity-b6d823fb44b606593470d5657524a98d.png\")
\n![\"Koji](\"/assets/images/packit-koji-builds-24b249549037f0d79822c9e851211e09.png\")
\n![\"Bodhi](\"/assets/images/packit-bodhi-updates-all-5b9ac688507f64dafe5284c5e9c7a4a9.png\")
Throughout the 2022 we have implemented support for building SRPMs in the Copr and slowly started introducing newly-onboarded projects to use Copr right from the start. The definitive switch to Copr has been done at the beginning of 2023. For more details, take a look at the relevant blog post, but let’s shortly describe the benefits:\nMost importantly, you can now use srpm_build_deps config option to specify the dependencies needed for the build. With the old solution, this process was manual, global and had to be done by Packit maintainers. Another advantage of being able to use Copr for SRPM builds is access to the SRPM artifacts.
From the beginning of the Packit project, for every Packit GitHub installation, we have required a Fedora account so we can be sure, that we are safe to use Fedora systems (like Copr or dist-git) on behalf of that user. Since we automate various tasks for you, we’ve made it possible for you to perform this yourself. (Thanks to the user config field in the Fedora Account System.)\nIf you are interested in how this works, take a look at the blog post we’ve prepared for you: https://packit.dev/posts/fas-verification-automation/
If you wonder why we check permissions for the installation, we have good news for you. This year, we plan to improve the permission schema, do the checks for each job, and require only what is needed. But more about the plans for 2023 later.
![\"Self-mapping](\"/assets/images/verify-fas-355a7111420aea52229c20f33a86322c.png\")
If you have multiple connected projects (as we do) and work on a feature spanning more of them, the following feature might come in handy. You can use a commit command with a reference to the other pull request and Packit will use Copr builds from both pull requests during the tests. Want to know more? Check this blog post: https://packit.dev/posts/testing-farm-triggering/
![\"Test](\"/assets/images/test-for-external-build-90b12f4f5294499b998234a477d6dbd8.png\")
This one might not be relevant to most of our users, but we would still like to announce, that we’ve created a Python library for specfile manipulation. It can not only parse various weird spec files but also can edit them with as little diff as possible. Also, the code is really interesting so check it out. Now, it’s used by Packit and rebase-helper and you can watch this demo if you want to know more.\nIn case you’ve missed that, this is not the first time we’ve extracted a part of our codebase for wider usage – another nice example is a forge-independent Python library for GitHub/GitLab/Pagure API called OGR.
Having Copr builds available for your pull-requests is really nice, but you can now have VM image builds as well. It would be really wasteful to do this for each and every commit so we decided to trigger this by a /packit vm-image-build comment. Similarly to other jobs, Packit uses an external system to do the hard work. This feature is possible thanks to the Red Hat Image Builder. This feature is a fresh start on this journey and we are investigating the possibilities of Packit in this field. Check our documentation and let us know what you think.
![\"VM](\"/assets/images/vm-image-build-9778abe48e8d422ff8863368f4df2930.png\")
Do you wonder what we plan for you for the year 2023? That is not a secret. For some time, we have been opening our planning and since the last year, you can check our Kanban board since it has become the primary place we use on daily bases. (It used to be half-manually and half-automatically synced.)\nEvery quarter, our team sits down and discusses our plans for the next three months. We use MOSCOW (=MUST x SHOULD x COULD x WON’T) prioritisation method to group and compare all of our epics. The result of this time’s planning can be seen here.
Do you want to know how we decide and how you can influence us? It’s pretty easy. Firstly, we need to know about a bug or feature request. Secondly, the task needs to be worth the work. (And should be related to our mission.) We can’t work on everything so we need to pick the work with a bigger impact (a lot of projects will benefit from that or a significant benefit for a smaller group). So shortly, if you want something to be done: create an issue, provide a clear reasoning why we should do that and find other projects that can benefit from that.
And also, our project is open source. We are more than happy to help anyone contribute to our code base!
With that, I, personally, would like to thank all of the Packit team members for their outstanding work during the year. And I also would like to thank you, our users, for using our project, being kind, helpful and patient! I wish you all a happy new year and less mundane work as possible!
On behalf of the Packit team,\nFrantišek
", "url": "https://packit.dev/posts/2022-features", "title": "2022 for Packit", "summary": "As you will see in the following paragraphs, the year 2022 was really fruitful for the Packit project. Without further ado, let’s take a look at what the Packit team accomplished last year!", "date_modified": "2023-01-28T10:58:50.000Z", "author": { "name": "František Lachman", "url": "https://github.com/lachmanfrantisek" }, "tags": [ "2022", "yearly-features", "summary" ] }, { "id": "https://packit.dev/posts/pull-from-upstream", "content_html": "In the previous year, we automated the Fedora downstream release process in Packit.\nThe first step of the release process, propagating the upstream release to Fedora,\nis covered by the propose_downstream job.\nThis job updates the sources in Fedora, the spec file, and other needed files and creates pull requests with the changes\nin the dist-git repository.
The downside of this job is that for its execution, users need to install Packit Service GitHub/GitLab\napp since this job reacts only to GitHub/GitLab release webhooks.\nHowever, the person who maintains the package in Fedora may not be the upstream maintainer and may not have admin access\nto the upstream GitHub/GitLab repository.
To cover this case, we came up with a new job called pull_from_upstream, which aims to update Fedora dist-git similarly\nto propose_downstream, but is configured directly in the dist-git repository.\nLet's now look at how to set it up and how it works.
pull_from_upstream job reacts to a new bug in Bugzilla about a new upstream version\nof a project. The bug is automatically created by\nUpstream Release Monitoring.\nTo enable the Upstream Release Monitoring:
Add the upstream project (if it is not there yet)\nto Anitya and configure the mapping to a Fedora package:\n![\"Project](\"/assets/images/anitya-project-895fdf4a3840fb0f008e6e004219b65e.png\")
Enable the monitoring in the dist-git repository (Fedora Package Sources):
![\"Monitoring](\"/assets/images/dist-git-monitoring-072d1b24827060d7f1818cc11c3e47df.png\")
In Anitya, there are multiple backends you can configure the mapping for.\nBesides GitHub or GitLab, you can use e.g. PyPI, pagure, or\nmany others.\nAlso, be aware that there can be a delay in retrieving the new version,\nso the update to Fedora is usually not created instantly (e.g. for Python projects,\nit is better to configure PyPI backend rather than GitHub since the monitoring\nthere is much less delayed).
To automatically pull the upstream release as a reaction to the bug in Bugzilla, pull_from_upstream job\nneeds to be defined in the default branch\n(rawhide) of the dist-git repository in the Packit configuration file (see\nour documentation). The upstream_project_url\nneeds to be a URL pointing to a Git repository so that we can do git commands on it.\nIf not specified, upstream repository is not being cloned.
pull_from_upstream in actionLet's showcase the new job in action for the latest release of\nPackit itself.
As you can see in the Setup section above, the Upstream Release Monitoring is configured:\nthere is a PyPI project packitos in Anitya\nwith configured mapping to the Fedora package packit and the monitoring in the\npackit dist-git repository is enabled.\nWe could configure the mapping in Anitya from the GitHub project directly instead, and it would work as well. Just be aware that\nfor each Fedora package, there can be a mapping only from one project.
In Packit configuration file, we have configured the job and related options:
upstream_project_url: https://github.com/packit/packit
issue_repository: https://github.com/packit/packit
copy_upstream_release_description: true
jobs:
- job: pull_from_upstream
trigger: release
dist_git_branches:
- fedora-all
- epel-8
You can see that version 0.66.0 of Packit (packitos in PyPI) was released:
![\"Packit](\"/assets/images/packit-release-pypi-d9a9d2675c7d4349e41b296190e10665.png\")
When Upstream Release Monitoring retrieved this new version, it created a new bug:
![\"Bugzilla\"](\"/assets/images/packit-release-bugzilla-2b6ecea0deabb2e89a2c4e57838bfca8.png\")
This triggered Packit, and after checking the Packit configuration in dist-git\nand finding the pull_from_upstream job, this job was run.
Using the upstream_project_url from the configuration, Packit was able to get the needed information\nfrom the corresponding GitHub release:\n![\"Packit](\"/assets/images/packit-gh-release-8041fa5c1f87fee966813e716db076f1.png\")
As a result, pull requests for configured branches were created.\nHere is an example of one of the created pull requests and part of its content:\n![\"Dist-git](\"/assets/images/pull-from-upstream-pr-084101cf1b0cbbefbf0797ef6638c0d8.png\")
\n![\"Pull](\"/assets/images/pull-from-upstream-content-1465ffb64bb623bf4bda8d5accef38d0.png\")
Since we have configured the issue_repository, we could be\nalso notified about errors:\n![\"Pull](\"/assets/images/pull-from-upstream-issue-0699d8c149066d81d53dd2318043eabc.png\")
It is now also possible to retrigger the job, see\nthe details.
Also, if you need to do any change in the pull request, you need to locally fetch the source branch\nof the Packit's pull request and push it (with a fix) to your fork (as it is not possible to push to the branch\ncreated in the Packit's fork):
git fetch ssh://$USER.fedoraproject.org/forks/packit/rpms/$YOUR_PACKAGE.git refs/heads/*:refs/remotes/packit/*
git cherry-pick packit/$VERSION-$BRANCH-update-pull_from_upstream
pull_from_upstream has just been implemented; therefore, we encourage you to help\ntest it out and make it perfect! There are still some limitations (e.g. regarding upstreams,\nsee documentation), which we are trying to resolve as soon as possible.\nWe believe this functionality\ncould be beneficial for maintainers of Fedora packages and could even be integrated further.\nAny suggestions and feedback are welcomed\n(see contacts).
If you are interested in details of customization of\nthe pull_from_upstream job and in the whole downstream automation, make sure to check out\nour Fedora release guide as well!
Do you contribute to projects which depend on each other?\nWould you like to test changes spanning multiple repositories together before merging them to the main branch?\nThen look no further, Packit's new feature of the Testing Farm integration is what you are looking for!
To enable such testing, there is no additional configuration required in your packit.yaml, the typical Testing Farm configuration is sufficient.\nOnce you open a pull request with some changes, tests are going to run as usual with all dependencies being installed based on the test definition, e.g. from Fedora repositories.\nTo trigger tests with builds from a pull request in another repository, add a comment to the pull request of the form:
/packit test <namespace>/<repo>#<pr-id>
Based on this comment, Testing Farm will first install the recent successful builds created by Packit in the given pull request and then run the tests.\nIn order for this to work, there must be successful builds for the targets that you are running tests for.\nFor example, if you are testing against Fedora 36, the pull request that you want to install builds from must contain a successful Fedora 36 build by Packit.
Let's look at a simple example to demonstrate this feature better.\nThe Packit CLI uses a library called specfile to modify RPM spec files.\nRecently, specfile has added a new feature which makes accessing the Epoch field in the spec file more convenient and we would like to make use of this feature.\nHowever, the changes have not made it to a Fedora release yet, trying to use this feature will result in an error:
![\"Tests](\"/assets/images/testing_farm_failed-f53ec0611bf89aee0e9eedd30a992814.png\")
![\"Test](\"/assets/images/testing_farm_failed_log-b4f3f67d4ae5d36021eda7ef2f9d0030.png\")
As we can see in the screenshots, during artifact installation, the latest specfile release from Fedora was installed, however it lacks the feature that we are looking to test.\nLet's now retrigger the tests, but specify that we want to install builds from the pull request in specfile which introduced the changes:
![\"Retriggering](\"/assets/images/testing_farm_retrigger-b67508e5263e2ee7f49b367670fcdd80.png\")
Hooray! The copr builds from PR 165 were installed before the tests were run in Testing Farm which enabled us to test the feature inside Packit CLI.
We hope that this new feature makes upstream testing even more convenient than it previously was.\nThe feature is still quite new, and we would love to hear what you think about it.\nAs always, if you run into any trouble or have any ideas how to improve this functionality,\ndo not hesitate to reach out to us.\nWe will be happy to help.
", "url": "https://packit.dev/posts/testing-farm-triggering", "title": "Running tests with builds from another PR", "summary": "Do you contribute to projects which depend on each other?", "date_modified": "2022-12-21T00:00:00.000Z", "author": { "name": "František Nečas", "url": "https://github.com/FrNecas" }, "tags": [ "testing-farm" ] }, { "id": "https://packit.dev/posts/fas-verification-automation", "content_html": "As you may already know, for using Packit Service\nGitHub App we require our users to have a valid Fedora Account System account.\nWe were verifying the newcomers until now manually, but in recent weeks, we have implemented an automated solution\nfor it. Let's take a closer look at how it is done currently and what have we improved!
Formerly, the process of verification by us started by waiting for the users to provide\nus their FAS username, then checking whether the provided FAS account\nexists and matches, and finally, manually adding the account to our allowlist in the database. For the communication with\nnew users, we have used our packit/notifications\nrepository on GitHub where we created an issue for each new installation.
Although in general, this worked, it required human interaction and since we are not available 24/7, the verification wasn't immediate.\nWe wanted to simplify the process for both users and us.\nSince in FAS, everyone can set their GitHub login that is then publicly available, we decided to utilize this setting.
So how does the verification work now?
For each new GitHub installation, we first check whether there isn't a FAS account with the same login as the one\nthat triggered the installation. If we find such an account, we check whether the GitHub Username in this FAS account matches\nthe GitHub login of the one that triggered the installation. To get the information about the FAS accounts, we\nuse the fasjson-client library.\nIf this check doesn't prove any match, we create an issue in the\npackit/notifications repository as previously. This is what it looks like:
![\"Issue](\"/assets/images/notifications-repo-issue-aca66e4b420cfe5d05c205fcf0020f92.png\")
As you can see, it contains instructions on how to trigger the verification automatically. So, everything the person who installed the app needs to do is set the GitHub Username field in their FAS account (if they don't have it set\nalready) and then provide the FAS login via Packit comment command /packit verify-fas the-fas-account.
Once the user does this, our service runs the same verification again (with the FAS username provided in the command) and informs users about the status\nvia a comment in the same issue. The successful verification looks like this:
This should save both users and our time and hopefully make the onboarding process smoother for the newcomers.\nSince this is a pretty new feature,\nlet us know whether there is something that is not clear so that we can improve it.
", "url": "https://packit.dev/posts/fas-verification-automation", "title": "Automation of FAS verification in Packit Service", "summary": "As you may already know, for using Packit Service", "date_modified": "2022-05-24T00:00:00.000Z", "author": { "name": "Laura Barcziová", "url": "https://github.com/lbarcziova" }, "tags": [ "fas" ] }, { "id": "https://packit.dev/posts/downstream-automation", "content_html": "Finally, it's here. Now, you can do the whole Fedora release with the help of Packit.\nLet's take a look at how it works on an example of OGR, the Python library we develop.
The process of releasing a new version starts in the upstream repository.\nHere, we can see an upstream release:
![\"Upstream](\"/assets/images/upstream_release-529c0916055286b228c4e1b631529fa4.png\")
As the first step on our way to Fedora users, we need to get the new upstream release to the Fedora dist-git.\nThis is what we call propose-downstream job.\nHere is a snippet from the config file of OGR:
downstream_package_name: python-ogr
copy_upstream_release_description: true
jobs:
- job: propose_downstream
trigger: release
dist_git_branches:
- fedora-all
- epel-8
How does the propose-downstream work?\nAs a first step, the archive is saved to lookaside cache\nand after that, Packit updates the dist-git content (mainly sources file and spec-file)\nvia pull-requests for the specified branches. (Direct push is possible only for CLI by setting a\ncreate_pr option to false.)
If you use copy_upstream_release_description: true,\nas in the config above,\nthe changelog entry will use the GitHub/GitLab release description field.\n(Just make sure the formatting is compatible with spec-file.\nE.g. use - instead of * for lists to not create multiple changelog entries.)
And how is it triggered?\nPackit gets the information about the newly created release from GitHub/GitLab (via webhook),\nloads the config from the release commit and if there is a propose-downstream job\ndefined, the workflow begins.
Here are the pull-requests created by Packit:
![\"List](\"/assets/images/distgit_prs-cf5788b3b23d52d771960621f308eab8.png\")
And here are the details of the one created for f35 branch:
![\"Downstream](\"/assets/images/distgit_pr_detail-e34816e0dd354d7b35afc8131f517551.png\")
\n![\"Downstream](\"/assets/images/distgit_pr_specfile-134e1c00d39c6afb809ae31a5af19d66.png\")
Now, it's on downstream CI systems and maintainer to check the changes and merge\nthe pull-request.
If Packit sees a new commit in the configured dist-git branch, it submits a new build in Koji\nlike maintainers usually do. (The commits without any spec-file change are skipped.)
![\"List](\"/assets/images/koji_builds-2f1af2ff0b81650da2cef9d25fcdaae4.png\")
Here is a job definition for the package we use as an example:
jobs:
- job: koji_build
trigger: commit
dist_git_branches:
- fedora-all
- epel-8
There is no UI provided by Packit for the job,\nbut it is visible across Fedora systems (like you can see in the following image)\nlike a manually created Koji build and you can utilise\nFedora Notifications\nto get informed about the builds.
![\"Build](\"/assets/images/distgit_pr_build_status-3f4561f6c2fbdaaf76616bd060e80b23.png\")
Once Packit is informed (via fedora-messaging bus) about the successful Koji build,\nit creates a new update in Bodhi for you.
![\"List](\"/assets/images/bodhi_updates-bb4320cda3965b1d3feff7b14e561373.png\")
Here is a job definition:
jobs:
- job: bodhi_update
trigger: commit
dist_git_branches:
- fedora-branched # rawhide updates are created automatically
- epel-8
The packit config is loaded from the commit the build is triggered from.
Here is an example of the resulting Bodhi update:
![\"Bodhi](\"/assets/images/bodhi_update_detail-c18320c042648314d31a9b4609aec94b.png\")
And that's all. The rest is on the users and maintainers to give the update enough Karma\nso the update gets to the users.
Does it look simple? Yes, it is. We try to automate\nas much as possible but still leave the space for human intervention where it is needed --\npull-request review and verification of the Bodhi update.\nOf course, in case of some errors, a human can (and should)\nreplace the work of a bot.\nOther manual, mundane and waiting tasks are replaced by Packit.
Please, try it yourself and let us know what do you think.\nThose jobs are really new and some issues might occur.\nBut we will try to fix those and if you have any suggestions\nfor improvement, please, create an issue so we can\nsee if the request is doable and we can try to implement it.\nAnd of course, code contribution is more than welcome as well.
", "url": "https://packit.dev/posts/downstream-automation", "title": "Downstream automation is here", "summary": "Finally, it's here. Now, you can do the whole Fedora release with the help of Packit.", "date_modified": "2022-05-06T00:00:00.000Z", "author": { "name": "František Lachman", "url": "https://github.com/lachmanfrantisek" }, "tags": [ "propose-downstream" ] }, { "id": "https://packit.dev/posts/copr-srpms", "content_html": "Let's find out how Packit builds your SRPMs in the Copr.
If you use Packit to build RPMs for your upstream code changes, likely,\nyou have already read about how does Packit build your SRPMs.\nIf not, then just a short recap:\nEach time an RPM build is triggered, Packit builds an SRPM and then submits\nthe created SRPM file to Copr where Copr takes care of building the actual RPMs.\nSince you can modify the behaviour of building SRPMs by defining actions,\nthis process needs to be run in an isolated environment. For this, we implemented our\nsandboxing mechanism,\nwhich simply runs the provided commands in an Openshift pod freshly created for each build.
This is a pretty good-functioning workflow, but it has some downsides which have become more and more annoying\nwith the growing user base. Because of the resources, we have set limits for Openshift pods running at one time.\nThis directly affects how many SRPM builds can run in parallel. As a result, when there are too many requests for (S)RPM builds,\nsome can get stuck in the queue while waiting for other builds to finish. Another inconvenience coming with pods being\nalways freshly created is copying the needed data into\nand from the pod. This has also cost us some months of desperate debugging of weird errors.\nAnother disadvantage is that users cannot easily configure dependencies for their actions run during building SRPMs.\nWe have to install the dependencies manually on-demand, but of course, which is not flexible.
We were thinking about improving the process for a long time but never reached any clear conclusion.\nThen in one of our architecture meetings, when we tried to solve another\nissue related to our sandboxing solution, Pavel Raiskup from Copr team asked us why didn't\nwe build the SRPMs directly in Copr. We knew that there is a way of building SRPMs in Copr,\nbut weren't aware of the details and how would this fit our use case.
After some research of the Copr custom source method, we\ndecided to give it a try. To make Copr build the SRPMs, Copr needs to be provided\nwith a script that will prepare the sources used to build an SRPM.\nTherefore, we created the packit prepare-sources command, which mostly reuses existing code that is run also in the sandbox\nworkflow. It prepares the specfile, archive and other sources and then moves\nthem to a separate directory. So with the new implementation,\nwith each request to run (S)RPM build, Packit sends a dynamically created \"script\" to Copr that invokes our new command.\nHere is what the script can look like:
#!/bin/sh
git config --global user.email \"hello@packit.dev\"
git config --global user.name \"Packit\"
resultdir=$PWD
packit -d prepare-sources --result-dir \"$resultdir\" --pr-id 676 --job-config-index 2 https://github.com/packit/ogr
You can see that a pull request should be checked out or which job defined\nin your Packit job config is the trigger of this action. And that's it! Copr finds the sources and builds SRPM from them.\nPackit listens to the messages about the start and end of the build and similarily as for RPM builds, reports the\nstate via commit statuses/checks and provides the URL with the logs.
Since this change is pretty significant, we wanted to start using this workflow gradually and catch all the problems\nbefore we get rid of the previous workflow for SRPMs.\nAt first, we tested how does the new solution work in our projects. The only disadvantage\nwas that the actual build process\ntakes a little longer than in sandcastle as we get an isolated environment where all the packages are installed for each new build.\nOn the other hand, Copr usually starts the build very soon after it is submitted, so no long wait time until some other build is finished.\nIn the initial implementation, we installed a list of dependencies\nwhich are present in our\nsandbox which also increased the build time a bit.
So as the following step we added the functionality to define dependencies for actions in the\nPackit config file with srpm_build_deps key.
Example of how the configuration of srpm_build_deps can look like:
actions:
create-archive:
- \"python3 setup.py sdist --dist-dir .\"
- \"sh -c 'echo packitos-$(python3 setup.py --version).tar.gz'\"
get-current-version:
- \"python3 setup.py --version\"
srpm_build_deps:
- python3-pip
- python3-setuptools_scm
We also decided that presence of this key in the config will be for some period an indicator to build the SRPMs in Copr. With this approach, anyone can configure\ntheir dependencies and play with adding and adjusting them as needed without directly breaking\nthe builds in their repository. When the builds in the PR pass, the configuration change can be merged and the new approach\nwill be used for the whole repository. We wanted\nto kick off this process and therefore started opening PRs with dependencies configuration for projects that use\nthe RPM builds functionality the most. During this phase, you can reach out to us with your feedback, so we can\nimprove it even more!
As a next step, we use the new approach for GitHub app installations made since September 6, 2022.
And as of January 10th 2023, we switched to building all SRPMs in Copr\nand thus got rid of using our sandbox for building SRPMs entirely.
Since we don't want to break your CI results because of missing dependencies, we will use the previously linked list of deps.\nAs the list is pretty long, we encourage you to define your dependencies on your own. If you\nbump into any troubles with setting up SRPM builds in Copr, please,\nreach out to us, we will be glad to help!
", "url": "https://packit.dev/posts/copr-srpms", "title": "Building SRPMs in Copr", "summary": "Let's find out how Packit builds your SRPMs in the Copr.", "date_modified": "2022-03-07T11:57:40.000Z", "author": { "name": "Laura Barcziová", "url": "https://github.com/lbarcziova" }, "tags": [ "srpm", "copr" ] }, { "id": "https://packit.dev/posts/2021-features", "content_html": "The previous year 2021 wasn't interesting only because of the increased usage of Packit\n(you can see more in the previous post).\nThe whole Packit team made a lot of improvements during the year.\nSome small, some really big. So, let's take a look at the most important ones!
The idea of having a dashboard for Packit service started as a\nGoogle Summer of Code 2020 project\nto provide a basic view of our service.\nThanks Anchit for starting this!\nNowadays, it's a core part of the project and it has replaced the result pages in plain HTML. Do you remember them?
The dashboard can be found at dashboard.packit.dev.
Following picture shows a more convenient and visually-appealing view of builds and test runs.\nFor better context, the relevant pages are a connected to each other.
![\"Dashboard:](\"/assets/images/dashboard-copr-1a172fb72c00bb1b71af74610fc8ce7d.png\")
If you want to see the overall picture, use our pipelines view that was created exactly for that:
![\"Dashboard:](\"/assets/images/dashboard-pipelines-03077187af2a61a8ab3a3fb1ed508d84.png\")
We consider our dashboard an important part of our service and are working on or planning more improvements:
propose-downstream one.From the very start, Packit is developed publicly in an open-source way.\nWe participate in various projects like Google Summer of Code, Red Hat Open Source Contest and Hacktoberfest.\nBut we are also very glad if anyone from our users contributes and fixes some pain point.\nTo help with that, we've renamed all our branches to main and rapidly enhanced our contribution guide(s).\nWe would like to encourage you not to be afraid of contributing to any of our projects.\nWe are prepared to help you with that.
If you want to keep an eye on what we are currently working on, check our Packit upstream work board on GitHub.
![\"GitHub:](\"/assets/images/github-project-3606aa0b741a1835854a5cbfe59bcb15.png\")
The year 2021 was a tough one for our test workflow. For those who don't know, we use Testing Farm as our test runner.\nAt the beginning of the year, we switched to the new Testing Farm API version\n(because the old one had died with the infrastructure it had been running on).\nUnlike the old version, the new one fully supports tmt as a test definition.
![\"Testing](\"/assets/images/testing-farm-results-976b2fa2b8055708c9bca93336fdad33.png\")
During the year, a set of supported environments was enhanced by centos-6, oraclelinux and aarch64.\nFor Red Hat teams, we added support for using the internal instance of the Testing Farm.\nLet us know if you are interested in this.\nBut no worries, you can use centos-stream and other publicly available environments.
Originally, the tests were run after the installation of the packages built using Copr from the source repository.\nNewly, you can skip this step and run the tests without any build. This allows you to use Packit&TestingFarm\nfor repositories containing only test definitions (e.g. QE teams).
![\"Testing](\"/assets/images/tf-no-build-9f7ecf53b820e6bfee6480256b97e69d.png\")
Lastly, we send some environment variables to the test environment and you can define your own if you want.
As we see, testing is a key feature for some teams and we still want to improve test use-cases\n-- let us know if you are missing anything (here or\nin the Testing Farm issue tracker).
To get users quickly know that we accepted the task and started working on it, we added two nice features\n-- :1 reaction for the comment that we are reacting on and task accepted commit status.
![\"Packit](\"/assets/images/thumbs-up-5f8d2df5d24049a4154408995c65dad3.png\")
Speaking of statuses, we switched to a more feature-rich API called GitHub Check Runs.\nIt allows us to create a separate result page where we can show more information\n-- e.g. more links when needed and more space for hints when there is a problem.\nYou can also find the run results on a separate Checks tab of the pull-requests page.\nThe check run page contains only the basic info and we don't want to replace a dashboard with this.\n(Because of the consistency between git-forges and to be able to link the related dashboard pages.)\nAnother feature of check runs you might find useful is being able to re-run the failed test with just one click\n(see the Re-run button in the following screenshot).
![\"Check](\"/assets/images/check-runs-a38bf2a5d1febf4d3933a066dec2696c.png\")
Inspired by other systems (like Zuul), for pull-requests we started using merge state\nso you can be sure the state we use is the same as the one with the pull-request being merged.\nWe are working with the Testing Farm team to add the support there as well so the test definition is consistent with the build.\nBut no worries, you can disable this if you don't want this behaviour.
One of our current initiatives is to help maintainers in the downstream part of the workflow as well.\nWe had the first part of that for some time in a form of propose-downstream job (you can expect more enhancements on this front),\nbut we newly support triggering Koji builds for new commits in dist-git.
When there is a new dist-git commit that contains Packit config with the defined koji_build job,\nPackit will trigger the Koji build for you.\nIt's fresh and basic so far so give us some time to announce this with more details.\nThe next step will be to create a Bodhi update when the build successfully finishes and that is\nwhat is currently being worked on.
Yes, we have a status page where you can check if everything is ok with our service.\nIt can be found at status.packit.dev\nOn the page, you can find a list of incidents we resolved or are trying to fix.\nIf you don't see any incident and still think the service isn't working as expected, please,\nlet us know (see contacts).\nAnother useful source of information is the pipelines view on our dashboard.
![\"Packit](\"/assets/images/status-1-161f9f8eab1e1c68007141a99dfda890.png\")
\n![\"Packit](\"/assets/images/status-2-870fd2bf13f962a7dc8e9ce1198436b5.png\")
As you see, we managed to accomplish a lot last year. And what you can expect this year?\n[Let us know]({{< ref \"faq#how-can-i-contact-you\" >}}) if you have some ideas and want to influence that!
", "url": "https://packit.dev/posts/2021-features", "title": "2021 for Packit", "summary": "The previous year 2021 wasn't interesting only because of the increased usage of Packit", "date_modified": "2022-01-12T08:23:38.000Z", "author": { "name": "František Lachman", "url": "https://github.com/lachmanfrantisek" }, "tags": [ "2021", "yearly-features", "summary" ] }, { "id": "https://packit.dev/posts/2021-in-numbers", "content_html": "Let's take a look on the year 2021 through some numbers.\nWe would like to show you some interesting statistics and charts\nthat can describe the work of Packit during the year 2021.\nIf you are more interested in new features,\nlet's take a look on our second post.
As of now, we have 169 installations of our GitHub application and 41 of them is from the year 2021.\nLooking at the monthly numbers below, it looks like we are getting back to shape.
![\"GitHub](\"/assets/images/github-installations-9dab680b453ba424a9fffa744270e432.png\")
Compared to the year 2020 when we made 28 430 Copr builds for our users,\nwe made 4.6 times more in the year 2021: 133 222 Copr builds.\nFor those who remember the start of our project,\nwe had a goal of 5 thousand for the FLOCK 2019.\nWe are now two digits ahead!\nAnd if you are wondering how active is our user on Copr,\nwe've created 2/3 of all the new Copr projects during the year.
To made this happen, we've created 36 133 source RPM files in the year 2021.
![\"Copr](\"/assets/images/copr-builds-dd34dfb527eb67affe3ddfad09436f25.png\")
Sadly, we started saving the submit time of the test runs in June\nso we have numbers only for the second half of the year.\nThe numbers are not so high as for the builds but still 18 498 test runs.
![\"Test](\"/assets/images/test-runs-e97a55c365a585076c678f29f29b3fd4.png\")
![\"Top20](\"/assets/images/top20-copr-builds-02b2a99641f6d7005a189512c9b1f7a0.png\")
![\"Top20](\"/assets/images/top20-test-runs-a6d4a360be98fb3f66fb65f0d5a46be0.png\")
Fedora EL Niño (ELN) is such an\nawesome idea. It enables building rawhide packages in two distinct buildroots:
This way you can make sure that your new upstream release builds fine in the\nnext RHEL.
But this feedback might be a little bit too late: the upstream\nrelease already happened and the code was imported in Fedora dist-git, so\nfixing an issue will require repeating the whole process. Wouldn't it be better\nto know if the upstream change builds fine in ELN while working on the\ncode?
Oh, wait!
If your GitHub project is not using Packit yet, here's a\nguide how to start.
Once it's set up, you need to make sure that your pull requests are also being\nbuilt in the fedora-eln target:
jobs:
- job: copr_build
trigger: pull_request
metadata:
targets:
- fedora-development
- fedora-eln
With this config, changes from every pull request will be built in all\ndevelopment versions of Fedora (at the time of writing this, it's Rawhide and\nFedora 33) and in Fedora ELN.
Easy, right?
Packit can also trigger builds when you push to a branch. If you want to have\nup to date builds of your main branch for ELN and development versions of\nFedora, here's how to set it up:
jobs:
- job: copr_build
trigger: commit
metadata:
targets:
- fedora-development
- fedora-eln
branch: main
If you got here and you're still not sure why you'd need this, I can give\nyou a real-life example.
Recently, Jirka Konecny from the RHEL\nInstaller team reached out to us that they would love to use Packit as a CI\nsystem. He set it up and now all the anaconda PRs are being built and tested on\nFedora Rawhide x86_64.
![\"Anaconda](\"/assets/images/anaconda-rawhide-tests-passing-4fd8c7a3455a72981b0fe9509fdd48fb.png\")
Jirka continued and added Fedora ELN as an additional target. The build failed\nbecause one of build requirements was not available in ELN:
Fedora ELN - Developmental modular packages for the next Enterprise Linux release 2.7 kB/s | 2.3 kB 00:0
No matching package to install: 'metacity'
Not all dependencies satisfied
Error: Some packages could not be found.
Since the team discovered this during their upstream development process, they\ncan react to the issue right away. It would have been pretty late if they found this\nwhile the next major RHEL is reaching alpha - at this moment they should\nhave enough time to fix the problem and make sure anaconda builds fine in ELN.
So, are you convinced? Let us know if you need help setting up Packit in your\nupstream repositories :)
", "url": "https://packit.dev/posts/fedora-eln", "title": "Working on the next major RHEL release, in your upstream repo", "summary": "Fedora EL Niño (ELN) is such an", "date_modified": "2020-10-04T00:00:00.000Z", "author": { "name": "Tomáš Tomeček", "url": "https://github.com/TomasTomecek" }, "tags": [ "downstream" ] } ] }