r/devops • u/Mukul-nst • 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
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.