gitea-ci-library/skills/ci-container-build/SKILL.md

name, description, activation-gate, category, impact

name	description	activation-gate	category	impact
ci-container-build	Creating or modifying CI container build workflows. Activates when consumer needs to build a custom CI container image (multi-tool image for tests, linting, validation) that is pushed to a container registry for use in other pipeline jobs.	User mentions CI container, custom CI image, ci-container-build, Dockerfile for CI tools, multi-tool container, or needs to build/push a container that other CI jobs will use as their runtime environment.	ci	high

CI Container Build — Template

Template jolla consumer luo oman CI-kontin build-workflown. Kontti sisältää useamman työkalun yhdistelmän (esim. helm + kubeconform + xsltproc), jota muut jobit käyttävät ajonaikaisena ympäristönä.

Rakenne

Vain workflow_dispatch — ei automaattista buildausta koskaan. Kontti buildataan manuaalisesti Gitea Actions UI:sta. Tiedoston ilmestyessä main-haaraan workflow näkyy välittömästi Actions-tabissa ajettavana.

Build-prosessi lataa ensin config-provider.yml:llä DOCKER_REGISTRY:n conf-tiedostosta, sitten buildaa ja puskaa kontin.

Kun kontti on pushattu registryyn, se on muiden pipeline-jobien käytettävissä latest-tägillä — rebuild = käyttöönotto. Mitään versioviittauksia ei tarvitse päivittää.

Nimeäminen

CI-kontin build-workflow noudattaa samaa nimeämiskonventiota kuin muutkin tiedostot .gitea/workflows/-kansiossa:

<komponentti>.ci-feature.yml                  ← feature-haaran reititin
<komponentti>.ci-main.yml                     ← main-haaran reititin
<komponentti>.<testityyppi>.yml               ← yksittäinen testi tai operaatio
<komponentti>.ci-container-build-<kontti>.yml ← CI-kontin build-workflow
<komponentti>.gitea-env.conf                  ← komponenttikohtainen konfiguraatio

Single repossa <komponentti> jätetään pois — tiedostot ovat suoraan ci-feature.yml, ci-main.yml, <testityyppi>.yml, ci-container-build-<kontti>.yml.

Monorepossa prefiksi pitää komponentin tiedostot yhdessä: ls <komponentti>.* löytää kaikki kerralla. Olemassaolevia prefiksejä ei saa poistaa.

Esimerkkejä:

.gitea/workflows/chart.ci-container-build-helm.yml
.gitea/workflows/api.ci-container-build-node.yml
.gitea/workflows/ci-container-build-bats.yml    ← single repo

Template

Korvaa kaikki __SUURAAKKOSET__-placeholderit projektin todellisilla arvoilla. Ainoastaan ${{ ... }}-syntaksilla merkityt Gitea Actions -muuttujat ovat ajonaikaisia eikä niitä korvata.

Luo .gitea/workflows/__KOMPONENTTI__.ci-container-build-__KONTTI__.yml (single repo: ci-container-build-__KONTTI__.yml):

name: CI Container Build & Push
on:
  workflow_dispatch:
    inputs:
      config_path:
        required: true
        type: string
        description: 'Polku .gitea-env.conf-tiedostoon (esim. .gitea/workflows/chart.gitea-env.conf)'
      dockerfile_path:
        required: true
        type: string
        description: 'Polku Dockerfileen (esim. ci-helm.Dockerfile)'
      image_name:
        required: true
        type: string
        description: 'Kontin nimi ilman registry-polkua (esim. ci-helm)'
      tag:
        required: true
        type: string
        default: 'latest'
        description: 'Image-tägi'

jobs:
  load-config:
    uses: __OWNER__/gitea-ci-library/.gitea/workflows/config-provider.yml@v1
    secrets: inherit
    with:
      config_path: ${{ inputs.config_path }}

  build-push:
    needs: [load-config]
    uses: __OWNER__/gitea-ci-library/.gitea/workflows/ci-container-build-push.yml@v1
    secrets: inherit
    with:
      env_json: ${{ needs.load-config.outputs.env_json }}
      dockerfile_path: ${{ inputs.dockerfile_path }}
      image_name: ${{ inputs.image_name }}
      tag: ${{ inputs.tag }}

Käyttö

Gitea Actions UI:sta (heti kun tiedosto on main-haarassa):

Gitea → Actions → CI Container Build & Push → Run workflow

config_path:      .gitea/workflows/__KOMPONENTTI__.gitea-env.conf
dockerfile_path:  ci-__TYÖKALU__.Dockerfile
image_name:       ci-__TYÖKALU__
tag:              latest

Dockerfile

Dockerfile yhdistää tarvitut työkalut yhteen konttiin. Molemmat tavat kelpaavat:

# Tapa A: COPY --from toisesta imagesta
FROM __BASE_IMAGE__:__VERSION__
COPY --from=__SOURCE_IMAGE__:__VERSION__ /path/to/binary /usr/local/bin/
RUN apk add --no-cache __PAKETIT__    # Ei koskaan git:iä — kloonaus kuuluu pipelinelle

# Tapa B: curl-lataus (normaali Dockerfilessa)
FROM __BASE_IMAGE__:__VERSION__
RUN apk add --no-cache curl __PAKETIT__ && \
    curl -fsSL __URL__/__BINARY__.tar.gz | tar xz -C /usr/local/bin && \
    apk del curl

COPY --from on kevyempi (ei curl-asennusta). curl on selkeämpi kun binääri tulee suoraan GitHub Releasesista tai vastaavasta.

Mitä EI kannata tehdä

• Älä lisää workflow_call-triggariä — CI-konttia ei koskaan buildata automaattisesti
• Älä poista <komponentti>.-prefiksiä olemassaolevista tiedostoista — ne kuuluvat monorepo-nimeämiskonventioon
• Älä sisällytä CI-konttiin mitään sovelluskoodia — vain työkalut
• Älä koskaan asenna git:iä CI-konttiin — repon kloonaus ja checkout ovat Gitea Actionsin natiiveja operaatioita, eivät kontin vastuulla. Git paisuttaa konttia turhaan ja luo harhan että kontti hallitsee repoa