Community Package Build Action

This repository contains GitHub Actions workflows and a custom action for building and managing packages for the Community repository. The system is designed to handle both AUR (Arch User Repository) packages and custom community packages.

1. Overview
2. Workflows
   • AUR Package Build
   • Build Package
3. Custom Action
4. Usage
5. Input Parameters
6. Environment Variables
7. Secrets
8. Build Process Steps
9. Customization
10. Contributing

This project automates the process of building, signing, and publishing packages for the Community repository. It supports both AUR packages and custom community packages, with different workflows for each type. The action provides visual feedback with a custom blue-based color scheme and integrates with Telegram for status notifications.

File: aur-package-build.yml

This workflow is triggered by repository dispatch events with types starting with 'aur-*' or manually through the workflow dispatch. It's designed to build packages from the Arch User Repository (AUR).

Key features:

• Supports manual and automated triggering
• Uses a custom Docker container (talesam/community-build:1.6.5) for the build environment
• Handles AUR package building, signing, and publishing
• Supports debug sessions with tmate
• Integrates with Telegram for notifications
• Captures and reports build duration

File: build-package.yml

This workflow is for building custom community packages. It can be triggered by repository dispatch events (except those starting with 'aur-*') or manually through the workflow dispatch.

Key features:

• Supports multiple branch types (testing, extra, stable)
• Allows creation of new branches
• Uses a custom Docker container for the build environment
• Handles package building, signing, and publishing
• Supports debug sessions with tmate
• Integrates with Telegram for notifications
• Captures start and end times to calculate build duration

File: action.yml

This is the core action used by both workflows. It defines the steps for building, signing, and publishing packages.

Key features:

• Elegant color-coded terminal output
• Configurable build environment
• Support for custom package repositories
• GPG signing of packages
• Publishing to GitHub releases
• Pushing to custom package repositories
• Updating repository databases
• Cleaning old packages (see below)
• Visual progress tracking with step numbering (steps 1/4 through 4/4)

After uploading, the action runs scripts/update-repository.sh on the repository server. It:

• keeps only the newest version of each package, compared with vercmp, as pacman compares them. The package name is everything before the last three fields of the file name (pkgver, pkgrel and arch never contain a hyphen), so linux-big-nvidia and linux-big-nvidia-580xx stay two packages;
• rebuilds the database aside and moves it into place, so pacman never downloads a missing or half-written one;
• takes a lock (flock), so builds finishing together update the database one at a time instead of overwriting each other;
• fails the build when a package it uploaded is not in the database — for example because the repository already has a newer version. Publish a rollback with a higher pkgrel or an epoch.

The server needs bash, pacman (for repo-add, vercmp and bsdtar) and flock. Every connection to it is retried, so a server refusing connections under load delays a build instead of losing it.

Test it locally, on real packages and the real repo-add:

tests/test-update-repository.sh

Each build has one Telegram message: the first step sends it and every later step edits it, so the chat shows the build's current step instead of one message per step. A message that cannot be edited is sent anew, and that one is edited from then on. tests/test-telegram.sh checks it against a fake Bot API.

To use these workflows and the custom action in your repository:

1. Copy the workflow files (aur-package-build.yml and build-package.yml) to your .github/workflows/ directory.
2. Copy the action.yml file to the root of your repository.
3. Set up the required secrets in your GitHub repository settings.
4. Trigger the workflows manually or set up repository dispatch events to automate the process.

The custom action supports the following input parameters:

• build_env: Build environment (testing, extra, stable, or aur)
• source: Custom package repo source
• manjaro_branch: Manjaro branch to build
• custom_repo: Custom repo
• multilib: Build multilib package
• repo: Package repo
• gpg_key: GPG signing key
• gpg_passphrase: GPG passphrase
• git_branch: Extra repository to build package
• extra_command: Extra command to run before building
• extra_package: Extra package to build
• tmate: Run tmate for debugging
• repo_mirror: Mirror to use in build
• repo_dev: Development repository
• pacman_mirror: Specific mirror to override automatic selection
• publish_github: Publish package on GitHub
• push_to_repo: Push package to repository
• update_db: Update repository database
• repo_host: Repository host
• repo_user: Repository user
• repo_port: Repository port
• repo_dir: Repository directory
• github_token: GitHub token for authentication
• telegram_token: Telegram bot token for notifications
• telegram_chat_id: Telegram chat ID for notifications
• branch_type: Branch type (testing, extra or stable)
• url: Repository URL
• new_branch: Name of the new branch
• package_name: Package name
• aur_package_dir: Directory containing the AUR package
• start_time: Workflow start time
• start_timestamp: Workflow start timestamp as epoch seconds
• repo_origem: Source repository
• branch_fullname: Full name of the source branch

The workflows use the following environment variables:

• PACKAGE_NAME: Name of the package to build
• AUR_URL: URL of the AUR package
• BRANCH_TYPE: Type of branch (aur, testing, extra, stable)
• BUILD_ENV: Build environment
• NEW_BRANCH: Name of the new branch to create or use
• TELEGRAM_TOKEN: Telegram bot token for notifications
• CHAT_ID: Telegram chat ID for notifications
• BRANCH_ORIGEM: Origin branch name
• REPO_ORIGEM: Origin repository URL
• REPO_NAME: Repository name
• BRANCH_FULLNAME: Full name of the branch of origin

The following secrets are required:

• PKGBUILD_KEY: SSH key for accessing the package build server
• GITHUB_TOKEN: GitHub authentication token
• GPG_PRIVATE_KEY: GPG private key for signing packages
• PASSPHRASE: Passphrase for the GPG key
• TOKEN_BOT: Telegram bot token
• CHAT_ID: Telegram chat ID for notifications
• PKGBUILD_HOST: Hostname of the package build server
• PKGBUILD_USER: Username for the package build server
• PKGBUILD_PORT: SSH port for the package build server
• PKGBUILD_DIR: Directory on the build server for storing packages
• REPOSITORY_TOKEN: Token for repository operations (optional)
• ORGANIZATION_TOKEN: Token for organization operations (optional)

The build process is divided into 4 main steps:

• Set up the build environment
• Clone source repository
• Configure system and repositories
• Import GPG key

• Build the package using makepkg
• Sign the package with GPG
• Generate checksums
• Push the package to the repository

• Clean old package versions
• Update repository database
• Prepare package for release (7z compression if needed)

• Create GitHub release (if enabled)
• Calculate and report build duration
• Send completion notification

The process includes elegant terminal output with color-coded messages and detailed progress tracking through Telegram notifications.

You can customize the build process by:

• Modifying the action.yml file to add or remove steps
• Adjusting the input parameters in the workflow files
• Changing the Docker image used for the build environment
• Adding custom commands in the extra_command input
• Customizing the color palette for terminal output

Contributions to improve the workflows or the custom action are welcome. Please submit pull requests or open issues to discuss potential changes or improvements.