Skip to main content
The GitHub Webhook Server provides comprehensive CI/CD integration for automating build, test, and deployment workflows.

Container Building and Publishing

Automatically build and publish container images to container registries.

Configuration

Global Docker Registry Access:
docker:
  username: your-docker-username
  password: your-docker-password
Repository-specific Container Configuration:
repositories:
  my-project:
    container:
      username: registry-user
      password: registry-password
      repository: quay.io/my-org/my-project
      tag: latest
      release: true  # Push with release tag on new releases
      build-args:
        - BUILD_VERSION=1.0.0
        - ENVIRONMENT=production
      args:
        - --format docker
        - --no-cache

Build Triggers

Containers are built automatically when:
  1. PR is opened or synchronized - Build container for testing
  2. PR is merged to protected branch - Build and push to registry
  3. New release is created - Build and push with release tag (if release: true)

Manual Container Build

Trigger container builds via comment commands:
# Build and push container
/build-and-push-container

# Build with custom build args
/build-and-push-container --build-arg VERSION=2.0

# Retest container build
/retest build-container

Build Process

  1. Clone repository at PR commit SHA
  2. Run podman build with configured args and build-args
  3. Tag image with configured tag
  4. Push to configured registry (if not a draft PR)
  5. Report build status via GitHub check run

Multi-registry Support

Support for multiple container registries:
  • Docker Hub (docker.io)
  • GitHub Container Registry (ghcr.io)
  • Quay.io (quay.io)
  • Any OCI-compliant registry

Container Build Requirements

  • Dockerfile in repository root
  • Podman or Docker available in webhook server environment
  • Registry credentials configured
  • Privileged mode enabled (for containerized deployments)
Docker Compose Example:
services:
  github-webhook-server:
    image: ghcr.io/myk-org/github-webhook-server:latest
    privileged: true  # Required for container building
    volumes:
      - "./webhook_server_data:/home/podman/data:Z"

PyPI Package Publishing

Automatically publish Python packages to PyPI when new releases are created.

Configuration

repositories:
  my-project:
    pypi:
      token: pypi-AgEIcHlwaS5vcmc...  # PyPI API token

Publishing Workflow

  1. Trigger: New GitHub release is created
  2. Process:
    • Clone repository at release tag
    • Build package using python -m build
    • Upload to PyPI using twine upload
    • Report status via GitHub check run

Requirements

  • Valid pyproject.toml or setup.py in repository root
  • PyPI API token with upload permissions
  • Package version matches release tag

Error Handling

  • Build failures reported as failed check run
  • Upload failures logged and reported
  • Existing package versions handled gracefully

Tox Testing Integration

Run Python tests using tox with branch-specific test environments.

Configuration

Basic Configuration:
repositories:
  my-project:
    tox:
      main: all  # Run all tox environments for main branch
      develop: unit,integration  # Run specific envs for develop
    tox-python-version: "3.12"  # Python version for tox
Branch-specific Test Environments:
repositories:
  my-project:
    tox:
      main: all
      dev: testenv1,testenv2
      feature: unit

How It Works

  1. PR opened/synchronized: Server identifies target branch
  2. Environment selection: Uses configured tox environments for that branch
  3. Test execution: Runs tox -e <environments> in cloned repository
  4. Result reporting: Reports pass/fail via GitHub check run

Manual Test Triggering

# Rerun tox tests
/retest tox

# Run all tests
/retest all

Tox Configuration File

Your repository must contain a tox.ini file:
[tox]
envlist = py312,lint,type-check

[testenv]
deps = pytest
commands = pytest tests/

[testenv:lint]
deps = ruff
commands = ruff check .

[testenv:type-check]
deps = mypy
commands = mypy src/

Test Results

  • Test output captured and displayed in check run details
  • Failed tests include full traceback
  • Test summary shows passed/failed/skipped counts

Pre-commit Hook Validation

Automatically validate code quality using pre-commit hooks.

Configuration

repositories:
  my-project:
    pre-commit: true

Validation Process

  1. Trigger: PR opened, synchronized, or manual retest
  2. Execution:
    • Clone repository
    • Install pre-commit hooks
    • Run pre-commit run --all-files
    • Report results via check run

Manual Validation

# Run pre-commit checks
/retest pre-commit

Pre-commit Configuration

Your repository needs a .pre-commit-config.yaml file:
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.5.0
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer
      - id: check-yaml
      - id: check-added-large-files

  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.1.9
    hooks:
      - id: ruff
        args: [--fix]
      - id: ruff-format

Common Pre-commit Hooks

  • Code formatters: black, ruff-format, prettier
  • Linters: ruff, pylint, eslint, shellcheck
  • Type checkers: mypy, pyright
  • Security: bandit, safety, detect-secrets
  • Git hooks: trailing-whitespace, check-merge-conflict

Test Commands

Comprehensive test automation via comment commands.

Available Test Commands

CommandDescriptionExample
/retest allRun all configured tests/retest all
/retest toxRun tox tests/retest tox
/retest build-containerRebuild container/retest build-container
/retest python-module-installTest package installation/retest python-module-install
/retest pre-commitRun pre-commit checks/retest pre-commit

Python Module Installation Test

Validates that your Python package can be installed:
/retest python-module-install
Test Process:
  1. Clone repository
  2. Create clean virtual environment
  3. Run pip install . or pip install -e .
  4. Verify installation succeeded
  5. Report results

Permission Requirements

Most test commands require user to be in repository OWNERS file:
  • /retest commands: Requires OWNERS membership
  • /build-and-push-container: Requires OWNERS membership
  • Automated tests on PR events: No permission required

Branch Protection Integration

Integrate CI/CD checks with GitHub branch protection rules.

Required Status Checks Configuration

repositories:
  my-project:
    protected-branches:
      main:
        include-runs:
          - "tox"
          - "pre-commit"
          - "build-container"
          - "can-be-merged"
        exclude-runs:
          - "optional-check"

Default Status Checks

default-status-checks:
  - "WIP"
  - "can-be-merged"
  - "build"

Branch Protection Rules

branch-protection:
  strict: true
  require_code_owner_reviews: true
  dismiss_stale_reviews: false
  required_approving_review_count: 1
  required_linear_history: true
  required_conversation_resolution: true

Check Run Reporting

All CI/CD operations report status via GitHub Check Runs:
  • Queued: Check run created and queued
  • In Progress: Test/build running
  • Success: Operation completed successfully
  • Failure: Operation failed with error details

Check Run Details

Detailed output includes:
  • Command executed
  • Full console output
  • Error messages and tracebacks
  • Timing information
  • Links to artifacts (if applicable)

Performance Optimization

The webhook server optimizes CI/CD performance:

Repository Cloning Optimization

  • Smart cloning: Only clone when needed for check_run events
  • Early exit: Skip clone for non-completed check runs
  • Shallow clones: Use --depth=1 for faster clones
  • Can-be-merged optimization: Skip clone for failed can-be-merged checks
Benefits:
  • 90-95% reduction in unnecessary cloning
  • Saves 5-30 seconds per skipped clone
  • Reduced resource usage
  • Lower server load

Concurrent Test Execution

Tests run concurrently when possible:
# Multiple test commands execute in parallel
await asyncio.gather(
    run_tox_tests(),
    run_precommit_checks(),
    build_container(),
)

Deployment Configuration Examples

Docker Compose

version: "3.8"
services:
  github-webhook-server:
    image: ghcr.io/myk-org/github-webhook-server:latest
    ports:
      - "5000:5000"
    volumes:
      - "./webhook_server_data:/home/podman/data:Z"
    environment:
      - WEBHOOK_SERVER_DATA_DIR=/home/podman/data
    privileged: true  # Required for container building
    restart: unless-stopped

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: github-webhook-server
spec:
  containers:
    - name: webhook-server
      image: ghcr.io/myk-org/github-webhook-server:latest
      securityContext:
        privileged: true  # For container building
      env:
        - name: WEBHOOK_SERVER_DATA_DIR
          value: "/data"

Build docs developers (and LLMs) love