feat: Add apk and pacman packages to CI/CD pipelines#24
Conversation
Updated ci.yml and release.yml to install necessary dependencies (libarchive-tools and zstd) for building pacman packages, and configured fpm to generate .apk (Alpine) and .pkg.tar.zst (Arch) packages. Added build artifacts to .gitignore. Homebrew and NixOS deployment were already implemented in release.yml.
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
📝 WalkthroughWalkthroughThis PR extends Linux packaging support in GitHub Actions workflows. CI and release pipelines now build APK (Alpine Linux) and pacman (Arch Linux) packages alongside existing DEB and RPM formats. System dependencies for the new formats are installed, packaging matrix commands are expanded, and gitignore is updated to exclude the new artifacts. ChangesLinux package format expansion
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![amazon-q-developer[bot]](https://avatars.githubusercontent.com/in/1220912?s=60&v=4){kind=small}
There was a problem hiding this comment.
The changes successfully add APK and Pacman package support to the CI/CD pipelines. The implementation correctly adds required dependencies (libarchive-tools and zstd), generates packages using fpm with appropriate architecture mappings, and updates .gitignore with the new artifacts. The workflows maintain proper conditional execution for Linux-only package generation steps. No blocking issues found.
You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.
There was a problem hiding this comment.
Pull request overview
Adds additional Linux packaging formats to the existing CI and release workflows so the project can produce .apk (Alpine) and .pkg.tar.zst (pacman/Arch) artifacts alongside the existing .deb and .rpm outputs.
Changes:
- Extend CI workflow to build
.apkand pacman packages viafpm, and list them in generated artifacts. - Extend release workflow to build and upload
.apkand pacman packages to the release artifacts. - Ignore generated package artifacts and packaging directories (
dist/,tmp_install/) in.gitignore.
Reviewed changes
Copilot reviewed 2 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
.gitignore |
Ignores generated package artifacts and packaging output directories. |
.github/workflows/release.yml |
Adds dependencies and builds .apk + pacman packages during release packaging. |
.github/workflows/ci.yml |
Adds dependencies and tests .apk + pacman package generation in CI. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| fpm -s dir -t deb -n ado -v $VERSION -a $ARCH -C ./tmp_install . | ||
| fpm -s dir -t rpm -n ado -v $VERSION -a $RPM_ARCH -C ./tmp_install . | ||
| fpm -s dir -t apk -n ado -v $VERSION -a $ARCH -C ./tmp_install . | ||
| fpm -s dir -t pacman -n ado -v $VERSION -a $RPM_ARCH -C ./tmp_install . |
| ARCH="amd64" | ||
| RPM_ARCH="x86_64" | ||
| if [ "${{ matrix.target }}" = "aarch64-linux" ]; then | ||
| ARCH="arm64" | ||
| RPM_ARCH="aarch64" | ||
| fi | ||
| fpm -s dir -t deb -n ado -v $VERSION -a $ARCH -C ./tmp_install . | ||
| fpm -s dir -t rpm -n ado -v $VERSION -a $RPM_ARCH -C ./tmp_install . | ||
| ls -la *.deb *.rpm | ||
| fpm -s dir -t apk -n ado -v $VERSION -a $ARCH -C ./tmp_install . | ||
| fpm -s dir -t pacman -n ado -v $VERSION -a $RPM_ARCH -C ./tmp_install . |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/ci.yml:
- Line 69: The APK packaging step uses fpm -t apk -a $ARCH which writes
unsupported arch strings into the APK; add an APK_ARCH variable (or map existing
ARCH) to convert amd64->x86_64 and arm64->aarch64, then replace -a $ARCH with -a
$APK_ARCH in the fpm invocation (the fpm line with VERSION and ARCH); ensure
APK_ARCH is set before the fpm command so the apk package uses x86_64/aarch64.
In @.github/workflows/release.yml:
- Line 78: The apk package architecture passed to fpm is wrong because the
workflow uses ARCH (amd64/arm64) directly; update .github/workflows/release.yml
to define a new variable APK_ARCH that maps ARCH values to fpm's apk names (map
"amd64" -> "amd64" and "arm64" -> "aarch64"), and then replace the fpm
invocation to use -a $APK_ARCH instead of -a $ARCH so the generated apk metadata
uses the correct architecture value.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: eb3efdc3-975f-4fc2-8a28-505abf6ad36f
📒 Files selected for processing (3)
.github/workflows/ci.yml.github/workflows/release.yml.gitignore
| fpm -s dir -t deb -n ado -v $VERSION -a $ARCH -C ./tmp_install . | ||
| fpm -s dir -t rpm -n ado -v $VERSION -a $RPM_ARCH -C ./tmp_install . | ||
| ls -la *.deb *.rpm | ||
| fpm -s dir -t apk -n ado -v $VERSION -a $ARCH -C ./tmp_install . |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
For fpm package type "apk", what architecture values are valid, and should they be "x86_64/aarch64" instead of "amd64/arm64"?
💡 Result:
Valid architecture values for fpm when using package type "apk" are not limited to only "x86_64/aarch64". For fpm’s apk backend, fpm uses Alpine/apk package metadata field "arch"; when you pass -a/--architecture it will write that value into the generated control file (so whatever value fpm accepts/normalizes must match apk’s accepted arch strings). fpm itself also treats -a native specially, translating it to noarch for apk. 1) What fpm docs/code say about "apk" architecture handling - The fpm CLI reference indicates "apk" has no additional apk-specific options; architecture is still controlled via the general -a/--architecture option. It also notes special values -a all and -a native are translated into the correct value for your platform/target package type. [1] - In fpm’s apk.rb implementation, FPM::Package#architecture defaults to "noarch" when the architecture is nil or "native". [2] - So for fpm -t apk, if you specify "native" (or omit -a), the generated apk package will get arch = noarch. - Fpm docs show example valid values for --architecture such as x86_64/amd64, aarch64, native, all/noarch/any (these are general fpm architecture tokens, not apk-only). [3] 2) What apk itself accepts for the arch field - Alpine’s apk package format man page (apk-package(5)) lists the currently accepted default architectures for the "arch" field, including at least: noarch, aarch64, x86_64, plus many other ARM/MIPS/RISC-V/etc entries. It also states installation eligibility depends on matching one of the values in etc/apk/arch. [4] Therefore, for a typical 64-bit build, the correct apk arch strings are: - x86_64 for 64-bit x86 - aarch64 for 64-bit ARM 3) Should they be "x86_64/aarch64" instead of "amd64/arm64"? - For apk packages specifically, "amd64" and "arm64" are not among the default apk arch values listed by apk-package(5); instead, apk expects "x86_64" and "aarch64" for those CPU families. [4] - So yes: for fpm -t apk, you should generally use "x86_64" and "aarch64" rather than "amd64" and "arm64" (unless your fpm workflow explicitly translates these tokens for apk; the apk-package(5) authoritative list shows what the resulting package arch field must be). [4] Practical guidance - Use: fpm -t apk -a x86_64... for x86_64 targets; and fpm -t apk -a aarch64... for ARM64 targets. [4] - Avoid relying on -a native for apk builds; fpm’s apk implementation maps "native" to "noarch". [2]
Citations:
- 1: https://fpm.readthedocs.io/en/latest/cli-reference.html
- 2: https://github.com/jordansissel/fpm/blob/master/lib/fpm/package/apk.rb
- 3: https://fpm.readthedocs.io/en/latest/getting-started.html
- 4: https://man.archlinux.org/man/apk-package.5.en
Use apk-compatible architecture strings (x86_64/aarch64) when building -t apk
For fpm -t apk, the -a/--architecture value is written into the apk package’s arch field; Alpine’s accepted arch strings are x86_64 and aarch64, not amd64/arm64. Update the apk invocation to use an APK_ARCH value.
Suggested change
ARCH="amd64"
+ APK_ARCH="x86_64"
RPM_ARCH="x86_64"
if [ "${{ matrix.target }}" = "aarch64-linux" ]; then
ARCH="arm64"
+ APK_ARCH="aarch64"
RPM_ARCH="aarch64"
fi
fpm -s dir -t deb -n ado -v $VERSION -a $ARCH -C ./tmp_install .
fpm -s dir -t rpm -n ado -v $VERSION -a $RPM_ARCH -C ./tmp_install .
- fpm -s dir -t apk -n ado -v $VERSION -a $ARCH -C ./tmp_install .
+ fpm -s dir -t apk -n ado -v $VERSION -a $APK_ARCH -C ./tmp_install .
fpm -s dir -t pacman -n ado -v $VERSION -a $RPM_ARCH -C ./tmp_install .📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| fpm -s dir -t apk -n ado -v $VERSION -a $ARCH -C ./tmp_install . | |
| ARCH="amd64" | |
| APK_ARCH="x86_64" | |
| RPM_ARCH="x86_64" | |
| if [ "${{ matrix.target }}" = "aarch64-linux" ]; then | |
| ARCH="arm64" | |
| APK_ARCH="aarch64" | |
| RPM_ARCH="aarch64" | |
| fi | |
| fpm -s dir -t deb -n ado -v $VERSION -a $ARCH -C ./tmp_install . | |
| fpm -s dir -t rpm -n ado -v $VERSION -a $RPM_ARCH -C ./tmp_install . | |
| fpm -s dir -t apk -n ado -v $VERSION -a $APK_ARCH -C ./tmp_install . | |
| fpm -s dir -t pacman -n ado -v $VERSION -a $RPM_ARCH -C ./tmp_install . |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ci.yml at line 69, The APK packaging step uses fpm -t apk
-a $ARCH which writes unsupported arch strings into the APK; add an APK_ARCH
variable (or map existing ARCH) to convert amd64->x86_64 and arm64->aarch64,
then replace -a $ARCH with -a $APK_ARCH in the fpm invocation (the fpm line with
VERSION and ARCH); ensure APK_ARCH is set before the fpm command so the apk
package uses x86_64/aarch64.
| fi | ||
| fpm -s dir -t deb -n ado -v $VERSION -a $ARCH -C ./tmp_install . | ||
| fpm -s dir -t rpm -n ado -v $VERSION -a $RPM_ARCH -C ./tmp_install . | ||
| fpm -s dir -t apk -n ado -v $VERSION -a $ARCH -C ./tmp_install . |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
In fpm, for output type "apk", which architecture strings are expected in package metadata (e.g., x86_64/aarch64 vs amd64/arm64)?
💡 Result:
For fpm output type “apk” (Alpine package format), the architecture value written into the package info metadata field arch = ... comes directly from fpm’s --architecture / -a option (with native mapped to noarch), and is not limited to Android/NDK style strings. fpm’s APK backend writes pkginfo << "arch = #{architecture()}\n", where architecture() returns noarch if @architecture is nil or set to native [1]. So the expected architecture strings you should use are the ones fpm accepts for --architecture (valid values documented as x86_64/amd64, aarch64, native, all/noarch/any) [2], which correspond to Alpine/apk naming expected for the arch field. In practice, for the examples you gave, the fpm/apk metadata arch values you should expect are: - x86_64 -> x86_64 [2] - amd64 -> amd64 [2] - aarch64 -> aarch64 [2] Notes/edge cases: - If you don’t specify -a/--architecture, or if you pass -a native, fpm will set arch = noarch for apk output [1]. For additional context on what apk itself considers valid arch values, Alpine apk supports x86_64 and aarch64 among many others (it is not limited to just x86_64/aarch64) [3].
Citations:
- 1: https://github.com/jordansissel/fpm/blob/master/lib/fpm/package/apk.rb
- 2: https://fpm.readthedocs.io/en/latest/getting-started.html
- 3: https://github.com/docker-library/php/blob/f4e930a76363da0b3b2f034d8ffc0532b1f8e61a/8.4/alpine3.23/fpm/Dockerfile
Fix fpm -t apk architecture value in release workflow
.github/workflows/release.yml uses -t apk -a $ARCH where ARCH is amd64/arm64. For fpm’s apk backend, the package arch metadata is written directly from -a and fpm’s documented apk architecture values include amd64/aarch64 (not arm64), so ARM releases will carry wrong apk arch metadata. Introduce APK_ARCH and pass it to -a (map amd64 → amd64, arm64 → aarch64).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/release.yml at line 78, The apk package architecture
passed to fpm is wrong because the workflow uses ARCH (amd64/arm64) directly;
update .github/workflows/release.yml to define a new variable APK_ARCH that maps
ARCH values to fpm's apk names (map "amd64" -> "amd64" and "arm64" ->
"aarch64"), and then replace the fpm invocation to use -a $APK_ARCH instead of
-a $ARCH so the generated apk metadata uses the correct architecture value.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the .gitignore file to exclude various package artifacts and build directories. Feedback indicates that the actual CI/CD configuration files mentioned in the PR description are missing from the submission. Additionally, it is recommended to update the PR description to include all supported package formats and to modify the Makefile's clean target to handle the newly ignored files and directories.
| *.deb | ||
| *.rpm | ||
| *.apk | ||
| *.pkg.tar.zst | ||
| tmp_install/ | ||
| dist/ |
There was a problem hiding this comment.
The pull request title and description indicate that CI/CD configurations for generating and distributing packages were added. However, the current changes only include updates to the .gitignore file. The actual CI/CD configuration files (e.g., GitHub Actions workflows in .github/workflows/ or a .gitlab-ci.yml file) are missing from this pull request.
| *.deb | ||
| *.rpm |
There was a problem hiding this comment.
The .gitignore file includes patterns for .deb and .rpm packages, but these formats are not mentioned in the pull request title or description (which focus on apk and pacman). If these formats are also being supported, please update the PR description to reflect this for better documentation and clarity.
| tmp_install/ | ||
| dist/ |
There was a problem hiding this comment.
The tmp_install/ and dist/ directories are added to the ignore list, but they are not handled by the clean target in the Makefile. To maintain a clean build environment, consider updating the clean target in the Makefile to remove these directories and the generated package files:
clean:
rm -f doc test_main
rm -rf tmp_install/ dist/ *.deb *.rpm *.apk *.pkg.tar.zst![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 19fa589fa2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| fi | ||
| fpm -s dir -t deb -n ado -v $VERSION -a $ARCH -C ./tmp_install . | ||
| fpm -s dir -t rpm -n ado -v $VERSION -a $RPM_ARCH -C ./tmp_install . | ||
| fpm -s dir -t apk -n ado -v $VERSION -a $ARCH -C ./tmp_install . |
There was a problem hiding this comment.
The Linux matrix sets ARCH to amd64/arm64, then passes it to fpm -t apk -a $ARCH; for apk output, FPM writes that value directly into .PKGINFO (arch = ...) rather than remapping aliases, while Alpine package metadata expects architecture names like x86_64 and aarch64 (see Alpine’s APK spec and APKBUILD arch list). As a result, the released .apk files can be generated successfully but are rejected on Alpine with architecture mismatch, so this produces unusable release artifacts for both Linux targets.
Useful? React with 👍 / 👎.
Added CI/CD configurations to generate and distribute
.apkand.pkg.tar.zstpackages via fpm, and updated.gitignore.PR created automatically by Jules for task 15972007703790140599 started by @clpi
Summary by CodeRabbit