devs/cproof
1
2
Fork 1
Code Issues 43 Pull Requests 6 Actions Packages Projects 1 Releases Wiki Activity

[CI] Add automated Docker Hub publishing workflow #140

New Issue
Closed
opened 2026-06-29 08:53:45 +00:00 by jabber.developer · 1 comment
jabber.developer commented 2026-06-29 08:53:45 +00:00
Owner
Copy Link

Description

CProof currently relies on manual builds or external package repositories for distribution. To align with our open-source, decentralized philosophy and simplify deployment for users, we should provide an officially maintained Docker image.

This issue tracks the creation of a GitHub Actions workflow that automatically builds and publishes CProof Docker images to Docker Hub. Since we host on Gitea, this workflow will use the standard .github/workflows/ directory, which is fully supported by Gitea's Actions implementation.

Goals

  • Create a GitHub Actions workflow that builds the CProof Docker image
  • Publish images to Docker Hub (cproof/cproof)
  • Apply semantic versioning tags on release (v1.2.3, 1.2, 1)
  • Push latest and dev tags on main branch updates
  • Support multi-architecture builds (linux/amd64, linux/arm64)
  • Update README.md with Docker installation instructions

Implementation Details

1. Workflow Location

Create the file at: .github/workflows/docker-publish.yml

2. Workflow Configuration

Use the modern Docker Actions ecosystem (docker/login-action, docker/build-push-action, docker/metadata-action) for reliable tagging, caching, and multi-arch support.

name: Docker Build & Publish

on:
  push:
    branches: [ main ]
    tags: [ 'v*' ]
  pull_request:
    branches: [ main ]

permissions:
  contents: read
  packages: write

jobs:
  docker:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up QEMU
        uses: docker/setup-qemu-action@v3

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Login to Docker Hub
        if: github.event_name != 'pull_request'
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_TOKEN }}

      - name: Extract Docker metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: cproof/cproof
          tags: |
            type=ref,event=branch
            type=semver,pattern={{version}}
            type=semver,pattern={{major}}.{{minor}}
            type=sha

      - name: Build and push Docker image
        id: push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: ${{ github.event_name != 'pull_request' }}
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          platforms: linux/amd64,linux/arm64
          cache-from: type=gha
          cache-to: type=gha,mode=max

3. Dockerfile Considerations

  • Use a lightweight base image (e.g., alpine or distroless)
  • Run as a non-root user for security
  • Include all dependencies for OTR, PGP, OMEMO, and OX support
  • Reference existing Profanity Dockerfiles for dependency baseline

🔐 Secrets Required

Add the following to your Gitea repository settings:

  • DOCKER_USERNAME: Your Docker Hub username
  • DOCKER_TOKEN: A Docker Hub Access Token (preferred over password for security & 2FA compatibility)

✅ Acceptance Criteria

  • Workflow file is added to .github/workflows/docker-publish.yml
  • CI pipeline passes on main branch pushes and v* tag creations
  • Images appear on Docker Hub with correct tags (latest, dev, vX.Y.Z)
  • Multi-arch images are built and pushed successfully
  • README.md is updated with a Docker quick-start section
  • Workflow does not attempt to push on pull_request events

📚 References

### Description CProof currently relies on manual builds or external package repositories for distribution. To align with our open-source, decentralized philosophy and simplify deployment for users, we should provide an officially maintained Docker image. This issue tracks the creation of a GitHub Actions workflow that automatically builds and publishes CProof Docker images to Docker Hub. Since we host on Gitea, this workflow will use the standard `.github/workflows/` directory, which is fully supported by Gitea's Actions implementation. ### Goals - [ ] Create a GitHub Actions workflow that builds the CProof Docker image - [ ] Publish images to Docker Hub (`cproof/cproof`) - [ ] Apply semantic versioning tags on release (`v1.2.3`, `1.2`, `1`) - [ ] Push `latest` and `dev` tags on `main` branch updates - [ ] Support multi-architecture builds (`linux/amd64`, `linux/arm64`) - [ ] Update `README.md` with Docker installation instructions ### Implementation Details #### 1. Workflow Location Create the file at: `.github/workflows/docker-publish.yml` #### 2. Workflow Configuration Use the modern Docker Actions ecosystem (`docker/login-action`, `docker/build-push-action`, `docker/metadata-action`) for reliable tagging, caching, and multi-arch support. ```yaml name: Docker Build & Publish on: push: branches: [ main ] tags: [ 'v*' ] pull_request: branches: [ main ] permissions: contents: read packages: write jobs: docker: runs-on: ubuntu-latest steps: - name: Checkout repository uses: actions/checkout@v4 - name: Set up QEMU uses: docker/setup-qemu-action@v3 - name: Set up Docker Buildx uses: docker/setup-buildx-action@v3 - name: Login to Docker Hub if: github.event_name != 'pull_request' uses: docker/login-action@v3 with: username: ${{ secrets.DOCKER_USERNAME }} password: ${{ secrets.DOCKER_TOKEN }} - name: Extract Docker metadata id: meta uses: docker/metadata-action@v5 with: images: cproof/cproof tags: | type=ref,event=branch type=semver,pattern={{version}} type=semver,pattern={{major}}.{{minor}} type=sha - name: Build and push Docker image id: push uses: docker/build-push-action@v5 with: context: . push: ${{ github.event_name != 'pull_request' }} tags: ${{ steps.meta.outputs.tags }} labels: ${{ steps.meta.outputs.labels }} platforms: linux/amd64,linux/arm64 cache-from: type=gha cache-to: type=gha,mode=max ``` #### 3. Dockerfile Considerations - Use a lightweight base image (e.g., `alpine` or `distroless`) - Run as a non-root user for security - Include all dependencies for OTR, PGP, OMEMO, and OX support - Reference existing Profanity Dockerfiles for dependency baseline ### 🔐 Secrets Required Add the following to your Gitea repository settings: - `DOCKER_USERNAME`: Your Docker Hub username - `DOCKER_TOKEN`: A Docker Hub Access Token (preferred over password for security & 2FA compatibility) ### ✅ Acceptance Criteria - [x] Workflow file is added to `.github/workflows/docker-publish.yml` - [x] CI pipeline passes on `main` branch pushes and `v*` tag creations - [x] Images appear on Docker Hub with correct tags (`latest`, `dev`, `vX.Y.Z`) - [x] Multi-arch images are built and pushed successfully - [ ] `README.md` is updated with a Docker quick-start section - [x] Workflow does not attempt to push on `pull_request` events ### 📚 References - [GitHub Actions: Building and pushing Docker images](https://docs.github.com/en/actions/publishing-packages/publishing-docker-images) - [Gitea Actions Documentation](https://docs.gitea.com/usage/actions/introduction) - [Docker Buildx & Metadata Actions](https://github.com/docker/metadata-action) - [Profanity Dockerfiles (Reference)](https://git.jabber.space/devs/profanity)
jabber.developer added this to the Plans (2025-2026) project 2026-06-29 08:53:57 +00:00
jabber.developer self-assigned this 2026-06-29 08:54:02 +00:00
jabber.developer added the
Priority
Medium
3
 label 2026-06-29 08:54:11 +00:00
jabber.developer moved this to In Progress in Plans (2025-2026) on 2026-06-29 08:54:25 +00:00
jabber.developer moved this to Verification in Plans (2025-2026) on 2026-07-10 10:39:07 +00:00
jabber.developer commented 2026-07-11 21:39:28 +00:00
Author
Owner
Copy Link

Resolved by #157

Resolved by #157
jabber.developer moved this to Done in Plans (2025-2026) on 2026-07-11 21:39:33 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Compat/Breaking
Breaking change that won't be backward compatible
Kind/Bug
Something is not working
Kind/Documentation
Documentation changes
Kind/Enhancement
Improve existing functionality
Kind/Feature
New functionality
Kind/Security
This is security issue
Kind/Testing
Issue or pull request related to testing
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Low
4
The priority is low
Priority
Medium
3
The priority is medium
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
No Label
Priority
Medium
3
Milestone
No items
No Milestone
Projects
Clear projects
No project Plans (2025-2026)
Assignees
Clear assignees
admin jabber.developer jabber.developer2
No Assignees jabber.developer
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: devs/cproof#140
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?