Lector de Feeds
Mageia 10 Press
CI and LLM review on Fedora Forge with Forgejo Actions
Hi folks! Over the last couple of weeks, we have migrated nearly all the quality team's repositories from Pagure (the old Fedora forge) to the new, Forgejo-based Fedora Forge. As part of this, I've figured out a process for doing CI with Forgejo Actions. I also came up with a way to do automated LLM pull request reviews, for those interested in that.
For the impatient, you can just look at / copy the two workflows in python-wikitcms, but you'll at least need to read the stuff about runners below.
Forgejo Actions works very similarly to GitHub Actions, by design. You create a .forgejo/workflows directory in your project and define workflows in it. The syntax is almost entirely compatible with GitHub Actions, but with several missing features.
Some very commonly-used shared actions, like actions/checkout, are ported to Forgejo so you can use them directly. Other shared and third-party actions can be used by giving a full URL to them - e.g. uses: https://github.com/actions-ecosystem/action-remove-labels@2ce5d41b4b6aa8503e285553f75ed56e0a40bae0 # v1.3.0 - but whether a given action will work or not depends on whether it's written to assume it's running on public GitHub, and whether Forgejo has all the features it needs.
Probably the most noticeable difference with using GitHub Actions is runner availability and environment. If you have a public GitHub project you can define workflows with something like runs-on: ubuntu-latest; behind the scenes, GitHub maintains a farm of runners with various labels, of which ubuntu-latest is one, and your jobs will run on any available runner with that label. The available environments for public GitHub repos are a handful of Ubuntu, Windows and macOS versions.
The staging instance of Fedora Forge has a few universal runners you can use like this. Currently each has only one, unique, label, so you can't specify workflows with a label like fedora and have them run on any available runner; you have to just pick one of the labels, and your jobs will always run on that runner. Maybe this will get changed at some point. But the runners are available to all repos in the staging instance, so you can just define a workflow and get it run.
Currently the production instance has no universal runners like this; runners are limited to specific organizations. The releng and infra organizations have runners, and now I requested one, the quality organization has one too. If you want to run workflows for projects in a different organization, the first thing you'll need to do is file a ticket to request runner(s) for that organization. If you have admin access to an organization, you can see whether it has runners, and what labels they have, by visiting https://forge.fedoraproject.org/org/<organization>/settings/actions/runners.
Once your org has at least one runner, you can define workflows and they'll run, as long as you set the runs-on value to a label that at least one of the runners has.
However, you might be surprised by the default environment: it's currently Debian Bookworm. Until that gets fixed, you may be interested in the container directive for workflows, which lets you define any arbitrary container image to be used:
container: image: quay.io/fedora/fedora:latestThere is one little gotcha with this, though. Many GitHub actions, including checkout, are written in Node, but Fedora's stock container images don't have Node installed. So you have to install it before running checkout or anything else that uses Node.
Put it all together, and here's the workflow I've defined for doing CI on Python projects with Tox:
name: CI via Tox on: pull_request: types: [opened, synchronize] jobs: tox: runs-on: fedora container: image: quay.io/fedora/fedora:latest steps: - name: Install required packages run: dnf -y install nodejs tox git - uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 with: fetch-depth: 0 - name: Install Python interpreters run: for py in 3.6 3.9 3.10 3.11 3.12 3.13; do dnf -y install python$py; done - name: Test with tox run: toxThat runs whenever a pull request is opened or pushed (the on section). It expects a runner with the fedora label (the runs-on setting). It uses the fedora:latest container image from quay.io (the container setting). From that image, we install packages we're going to need - including nodejs (the first step). Then we run actions/checkout to check out the PR (the second step, the uses one). Then we install all the Python interpreters we need, and run tox (the final two steps). Of course, if your project isn't Python or doesn't use Tox, you'll have to tweak this a bit, but hopefully you get the general idea.
If you're security-minded, you might notice there's no permissions setting in this workflow. That's because Forgejo currently does not support fine-grained permissions in the automatically-generated workflow tokens. In Forgejo, the automatically-generated token always has full read/write privileges unless it's operating on a pull request from a fork, in which case it has only read permissions. Nothing finer-grained is possible at present. If you need something finer-grained, you have to generate a token manually, save it as a repository secret, and adjust your workflow (somehow) to use that and hide the automatically-generated token as far as is practically possible (that's outside the scope of this post).
So that's CI! What about LLM pull request review? Well, if you dislike or are not interested in that, stop reading now. If you are interested, here's a recipe:
name: AI Code Review on: pull_request_target: types: [labeled] jobs: ai-review: if: forgejo.event.label.name == 'ai-review-please' runs-on: fedora container: image: registry.gitlab.com/redhat/edge/ci-cd/ai-code-review:v2.3.0 steps: - name: Run AI Review env: AI_API_KEY: ${{ secrets.GEMINI_API_KEY }} run: ai-code-review --platform forgejo --pr-number ${{ forgejo.event.pull_request.number }} --post # this has to be a separate job because ai-code-review container does not have nodejs in it # also note this does not work for PRs from forks because of a forgejo bug # https://codeberg.org/forgejo/forgejo/issues/10733 remove-label: runs-on: fedora steps: - uses: https://github.com/actions-ecosystem/action-remove-labels@2ce5d41b4b6aa8503e285553f75ed56e0a40bae0 # v1.3.0 with: labels: ai-review-pleaseThat will cause the ai-code-review tool to review the pull request and post its analysis as a comment.
Just a couple of things to note here. I decided to have the LLM review happen only when a pull request is given a special label. LLM reviews are relatively expensive, and also quite verbose; you don't necessarily want one cluttering up the ticket any time a pull request is created or edited, and you may not want to make it possible for someone to charge some LLM usage to your account as often as they like just by creating or editing a pull request.
So, to use this recipe you have to create a label called ai-review-please in your repository. You can do this by going to "Issues", then clicking "Labels", then "New label". Give it whatever color and description you like. Any time you add that label to a PR, the review process will be triggered. Before adding the label to a PR you should probably make sure the PR is well-intentioned and not attempting any kind of prompt injection to get ai-code-review to disclose a secret or mess with the repository.
The other thing is you need an AI provider API key. In this recipe we have a Gemini API key saved as a repository secret called GEMINI_API_KEY. To create repository secrets, go to repository "Settings", then "Actions", then "Secrets", and click "Add secret". In the workflow, we make the repository secret called GEMINI_API_KEY (secrets.GEMINI_API_KEY) available in the container as the environment variable AI_API_KEY; ai-code-review reads it in from there. Gemini is the default LLM provider for ai-code-review. You can also use OpenAI or Anthropic by adding an --ai-provider argument to the ai-code-review call in the workflow (obviously, then, the secret you export as AI_API_KEY must be a valid key for that provider). I'm hoping that in the not-too-distant future, we'll have an LLM model provider in Fedora infra, running open source models, that we can use for this purpose; for now, unfortunately, we have to use the hyperscaler ones.
Finally, as noted in the comment, the workflow is intended to remove the ai-review-please label when it runs (so you don't have to remove it manually, then add it again, if you want another review later), but this does not currently work for pull requests from forks due to a Forgejo bug (because we're using pull_request_target the workflow token should have write permissions even for a fork PR, but it doesn't). If you use it on a fork PR, you'll have to remove the label manually once the workflow has triggered.
You can, of course, change the on block to be the same as the CI recipe if you want to have LLM review run automatically whenever a PR is created or edited - but do make sure whoever's paying the bills for the API key is OK with that, and monitor the repo to make sure nobody starts creating hundreds of PRs to try and blow your budget...and hope/pray nobody manages a successful prompt injection attack. On the whole I'd stick with the label (only repository admins can label PRs, so a non-admin attacker can't apply the label themselves to trigger the review).
Persistent live systems
Original kernel: Advanced, links
← Older revision Revision as of 19:29, 19 January 2026 (2 intermediate revisions by the same user not shown)Line 195: Line 195: # Add 6.6 kernel in skip.list per '''(*)''' above, and uninstall kernel(s) 6.6.x, which should also remove any 6.6.*-latest package. # Add 6.6 kernel in skip.list per '''(*)''' above, and uninstall kernel(s) 6.6.x, which should also remove any 6.6.*-latest package. It is ''possible'' to [https://bugs.mageia.org/attachment.cgi?id=15306 install nvidia470] - and probably similar for nvidia-current, but seldom worth the work and 1GB space! The free drivers work well. It is ''possible'' to [https://bugs.mageia.org/attachment.cgi?id=15306 install nvidia470] - and probably similar for nvidia-current, but seldom worth the work and 1GB space! The free drivers work well. + +=== Kernel maintenance === +Uninstall kernels to save space. Never uninstall the original kernel nor the currently running kernel! Note that in the boot menu you can only select between the original kernel and the latest installed - regardless of version number. So if you want to go back one version, boot on original, remove any you want and (re)install the version you want. Also see [[#Original_kernel|Original kernel]]. + +We have a helper: Beginning with Mageia 9 on 64 bit Live like on a 64 bit installed system, {{cmd|rok}}, [[Mageia_9_Release_Notes#remove-old-kernels|remove-old-kernels]] is installed. The updated 1.0.3+ version detects when it runs on a Live system and then keep max 2 kernels (of each flavour - note backport kernel is of another flavour) and does never uninstall the original kernel. rok runs occasionally in the background which means on slow USB dives the system may suddenly become sluggish for a while, and Xfce file managers pop up {{Bug|34964}}. To avoid such surprise you may want to disable rok from running automatically by launching it by {{cmd|rok -A0}} as root. == Custom Live ISO == == Custom Live ISO == Line 451: Line 456: === Original kernel === === Original kernel === −If {{menu|[F1]}} is shown, you can use it to toggle between booting the original kernel in the Live ISO, or the latest installed one in persistence. (The text after [F1] toggles "original" <-> "latest", indicating which is chosen). +If {{menu|[F1]}} is shown, you can use it to toggle between booting the original kernel in the Live ISO, or [[#Kernel_maintenance|the latest installed one]] in persistence. ''The text after [F1] toggles "original" <-> "latest", indicating which is chosen.'' ''NOTE: When persistence is encrypted, you can not select an updated kernel. See further in [[#Encryption|Encryption]].'' ''NOTE: When persistence is encrypted, you can not select an updated kernel. See further in [[#Encryption|Encryption]].'' + +''For the advanced user: The "latest" option in the Live boot menu relies solely on the soft links /boot/vmlinuz and /boot/initrd.img. It doesn't care what kernel version they link to, so if you need to restore booting from another kernel, you can do so by manually changing those links. +[https://bugs.mageia.org/show_bug.cgi?id=34951#c33 ''Further technical details'']'' === Boot command line === === Boot command line === MorganoErstellen/Bearbeiten einer Wiki Seite-de
Mageia 10 Entwicklung-de
Mageia 10 Development
Development Schedule
← Older revision Revision as of 10:39, 19 January 2026 Line 28: Line 28: | 2026-01-18 | 2026-01-18 | developers, packagers | developers, packagers −| +| 2026-01-19 |- |- | '''Beta''' | '''Beta''' Bcornec



