Skip to content

PRJ2 Naming Conventions

Date: 2026-01-09 Status: Accepted Context: PRJ2 student team deployment infrastructure

Decision

Adopt year-based naming conventions for Harbor projects, images, and Kubernetes resources.

Naming Structure

Component Pattern Example
GitHub repo prj2-{year}-{teamId} prj2-2026-group01
Team name (full) {year}-{teamId} 2026-group01
Harbor project prj2-{year} prj2-2026
Backend image {teamId}-backend group01-backend
Frontend image {teamId}-frontend group01-frontend
Full image path harbor.../prj2-{year}/{teamId}-backend:tag harbor.../prj2-2026/group01-backend:v1.0.5
Kubernetes namespace prj2-{year}-{teamId} prj2-2026-group01
ArgoCD Application prj2-{year}-{teamId} prj2-2026-group01
ApplicationSet file k8s/prj2/apps/{year}.yaml k8s/prj2/apps/2026.yaml
Database user/name {year}-{teamId} 2026-group01

Key Separations

  1. Year is extracted from the team name (2026-group01 → 2026)
  2. Team ID is the identifier within that year (2026-group01 → group01)
  3. Harbor project groups all teams for a cohort year

Rationale

Why year-based Harbor projects?

After: prj2-2026/group01-backend - Harbor UI doesn't like multiple '/' (needs flat image names) - One Harbor project per cohort year - Flat repository names (no nesting) - Easy end-of-year cleanup: delete entire prj2-2026 project

Why year-based ApplicationSets?

After: One {year}.yaml per cohort - Each file is self-contained for its year - Easy to archive: git rm k8s/prj2/apps/2025.yaml - Clear separation of concerns

Why extract year and teamId?

Derived values reduce duplication: - Harbor project = prj2-{year} (computed from year) - Namespace = prj2-{year}-{teamId} (computed from both) - Only need to specify year and teamId in ApplicationSet

Validation is simpler: - Year must be 4 digits - TeamId must be non-empty - Combined format is enforced by regex: ^([0-9]{4})-(.+)$

Consequences

from switching to 'prj2' to 'prj2-2026' harbor project:

Positive

  1. Cohort isolation - Each year is completely separate
  2. Easy cleanup - Delete year's Harbor project + ApplicationSet file
  3. Clear ownership - Image names show team ID directly
  4. Simpler permissions - One Harbor project per year, flat repos
  5. Better organization - Git history shows per-year changes

Negative

  1. Harbor project creation - Manual step per year (could automate)
  2. Robot account scope - Needs access to each year's project

Alternatives Considered

Alternative 1: Keep nested paths

prj2/2026-group01/backend

Rejected because: - Harbor permissions don't work well with nested paths - Cleanup requires deleting individual repos, not entire project - No cohort-level isolation

Alternative 2: Separate Harbor per team

prj2-2026-group01/backend

Rejected because: - Too many Harbor projects (one per team) - Admin overhead for project creation - No cohort-level grouping

Implementation

  1. Helm chart uses year and teamId as separate values
  2. _helpers.tpl computes derived names (harborProject, namespace, images)
  3. Provision script extracts year/teamId from team name
  4. GitHub workflow extracts year/teamId and builds to correct path
  5. ApplicationSets are year-specific files

References

  • k8s/prj2/helm-charts/prj2/templates/_helpers.tpl - Naming helpers
  • scripts/provision-team.sh - Team provisioning
  • .github/workflows/prj2-build.yml - CI/CD image naming
  • docs/prj2-onboarding.md - Operational guide