Skip to content

GitHub Actions for CI

Date: 2026-03-23 Status: Accepted Context: Choosing a CI system for building and publishing student application images

Decision

Use GitHub Actions with a reusable callable workflow that all student repositories consume. The platform team maintains a single workflow definition; student repos call it via workflow_call.

How it works

Student repo (FontysVenlo/prj2-2026-group01)
  └── .github/workflows/build.yml
        └── uses: FontysVenlo/idp/.github/workflows/prj2-build.yml
              │
              ├── Derives team name from repo name
              ├── Builds backend + frontend images (linux/amd64)
              ├── Pushes to Harbor (harbor.prod.fontysvenlo.dev/prj2-{year}/...)
              └── Tags commit with version (v1.0.{count}-{sha})

Rationale

  • GitHub Classroom — students already use GitHub via GitHub Classroom for repository management. Actions is the CI that comes with it — no extra accounts, no extra tools.
  • Free for education — GitHub Education provides free Actions minutes for classroom organizations.
  • Reusable workflow pattern — one workflow definition maintained by the platform team, consumed by all student repos. Students don't need to understand or maintain their CI pipeline (Tier 1), but they can inspect it and learn from it.
  • Transparent and close to the code — CI runs are visible in the student's own repository. Build failures show up on PRs. This supports students taking ownership of their pipeline and understanding the build-deploy cycle.
  • No extra infrastructure — no Jenkins server or GitLab runner to host and maintain.

Re-evaluate when

The right time to reconsider this decision is if we move away from GitHub — for example, toward a local or EU-friendly alternative (Gitea, GitLab). At that point, CI would be part of the broader platform migration.

Alternatives Considered

GitLab CI

  • ✅ Integrated platform (repo + CI + registry)
  • ❌ Would require migrating away from GitHub entirely
  • ❌ Self-hosted GitLab is heavy infrastructure
  • Rejected: Migration cost too high; we're invested in the GitHub ecosystem

Jenkins

  • ✅ Extremely flexible, plugin ecosystem
  • ❌ Extra infrastructure to maintain (Jenkins server, agents)
  • ❌ Not student-facing — builds happen "somewhere else", disconnected from the repo
  • ❌ Configuration is not in the student's repo
  • Rejected: Operational overhead and poor student visibility

Gitea + Woodpecker CI

  • ✅ Open-source, self-hostable, lightweight
  • ❌ Immature ecosystem compared to GitHub Actions
  • ❌ Would require migrating source hosting too
  • Rejected: Not mature enough; migration cost not justified

Consequences

Positive

  • Students see CI as part of their repository, not a separate system
  • Platform team maintains one workflow for all teams
  • Build failures are visible on pull requests — encourages fixing before merge
  • No CI infrastructure to host or maintain

Negative

  • Dependency on GitHub's availability and pricing (education tier)
  • Reusable workflows have limitations (e.g., debugging across repos can be harder)
  • GitHub Actions minutes are free but not unlimited — large cohorts could hit limits
  • Vendor lock-in to GitHub ecosystem