This action builds ArchLinux packages in a Docker container and optionally updates a package repository.
uses: Slinet6056/archpkg-build@v1
with:
package_name: pkg
gpg_private_key: ${{ secrets.GPG_PRIVATE_KEY }}
gpg_passphrase: ${{ secrets.GPG_PASSPHRASE }}
pkgs_path: test # optional
repo_name: test-repo # optional
repo_path: repo # optionalpackage_name: Name of the package to build (required)gpg_private_key: GPG private key for package signing (required)gpg_passphrase: Passphrase for the GPG private key (required)pkgs_path: Path to the directory containing package subdirectories (optional, default: ".")repo_name: Repository name (optional, for repository update)repo_path: Repository path (optional, for repository update)
- The action uses a Docker container based on the
archlinux:base-develimage. - It sets up a build environment and creates a non-root user for building packages and signing them.
- The specified package is built using
pikaur. - The built package is signed using the provided GPG key.
- If
repo_nameandrepo_pathare provided, the action updates the package repository.
After running this action, you can expect the following results:
- The built package (
.pkg.tar.zst) and its signature (.pkg.tar.zst.sig) will be available in the package's build directory. - If
repo_nameandrepo_pathare provided, the package repository will be updated with the new package. The updated repository, including the new package file, its signature, and the updated database files, will be available in the specifiedrepo_path.
These outputs can be utilized in subsequent steps of your workflow for various purposes.
strategy:
matrix:
pkgs: [pkg1, pkg2]
steps:
- uses: Slinet6056/archpkg-build@v1
with:
package_name: ${{ matrix.pkgs }}
gpg_private_key: ${{ secrets.GPG_PRIVATE_KEY }}
gpg_passphrase: ${{ secrets.GPG_PASSPHRASE }}- Ensure that your repository contains subdirectories named after each
package_namewithin thepkgs_path(default: "."). Each subdirectory should contain the necessaryPKGBUILDfile. - Store the complete GPG private key (including header and footer) and passphrase as separate secrets in your GitHub repository.
- When updating a repository, the
repo_pathwill be automatically created if it doesn't exist. - Automatic repository update may cause conflicts when using matrix strategy. To resolve this issue, you can use the Matrix Sequential Lock action. This action allows you to control the execution order of jobs, preventing conflicts during repository updates. For a specific implementation example, please refer to examples/advanced-workflow.yml.
This project is licensed under the MIT License. See the LICENSE file for details.