r/devops 2d ago

Discussion CI pipeline using Github actions

I started learning CI/CD using github actions after containerising my application and I have created CI pipeline for django app that runs test, builds and pushes image to github container registry.
I am sharing my yaml file for CI pipeline. Please do share your thoughts and where can i improve.

name: Test Pipeline 
on: 
  push:
jobs:
  test-backend:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:14
        ports:
          - 5432:5432
        env: 
          POSTGRES_USER: test_user
          POSTGRES_DB: erp
          POSTGRES_PASSWORD: 123456

    steps:
      - name: Checkout repo
        uses: actions/checkout@v4

      - name: setup python
        uses: actions/setup-python@v5
        with: 
          python-version: "3.13.5"

      - name: install dependencies
        run: pip install -r Backend/requirement.txt

      - name: run tests
        env: 
          DATABASE_URL: postgresql://test_user:123456@localhost:5432/erp
          DEBUG: 'True'
          ALLOWED_HOST: '*'
        run: |
          cd Backend 
          python manage.py test

  build-and-push-image:
    needs: test-backend
    permissions:
      contents: read
      packages: write
    runs-on: ubuntu-latest
    steps:
      - name: login to ghcr
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}


      - name: checkout repo
        uses: actions/checkout@v4


      - name: build image
        run: docker build -t ghcr.io/namespace/erp:${{ github.sha }} ./Backend


      - name: push image
        run: docker push ghcr.io/namespace/erp:${{ github.sha }}
0 Upvotes

14 comments sorted by

View all comments

2

u/Raja-Karuppasamy 2d ago

DEBUG: 'True' and ALLOWED_HOST: '*' in the test env is fine for CI, but worth a comment noting these should never leak into what gets built into the actual image, easy mistake to make later if someone copies this job as a starting point for a “real” deploy workflow.

bigger one: you’re tagging the image with ${{ github.sha }} only, no latest or version tag. that’s actually good practice for rollback purposes (don’t let past-me tell you otherwise, i learned this one the hard way), but make sure whatever deploys this image knows how to find the right sha, or you’ll end up manually digging through registry tags at 2am.

also packages: write permission scoped at the job level is the right call, a lot of people just set it at workflow level for everything, which is broader than it needs to be.

one thing missing: no caching for pip installs. actions/setup-python supports cache: 'pip' , small change, speeds up every run once your dependency list grows.