Releases

En release er et tagget øjebliksbillede af et repository, eventuelt med vedhæftede binære artefakter, tarballs eller andre filer. Releases vises på frem.sh/<org>/<repo>/releases og giver et stabilt, letlæseligt indeks over, hvad der blev leveret og hvornår. De er adskilt fra pakkeregistret: releases indeholder versionerede øjebliksbilleder af kildekode og build-artefakter, mens container-images og pakker til sprogøkosystemer hører hjemme i pakkeregistret.

Opret en release fra brugerfladen

1. Gå til Repository → Udgivelser → Ny udgivelse (frem.sh/<org>/<repo>/releases/new).
2. I feltet Tag navn vælger du et eksisterende tag eller skriver navnet på et nyt tag for at oprette det på den valgte branch eller commit. Semantisk versionering (v1.0.0, v2.3.1-rc.1) anbefales.
3. Angiv Udgivelsestitel. Den vises som overskrift på siden med releases.
4. Skriv release notes i tekstfeltet. Markdown understøttes. Medtag et resumé af ændringerne, breaking changes, vejledning til opgradering og tak til bidragydere.
5. Vedhæft release-assets ved at trække filer hen på upload-området (Slip filer eller klik her for at uploade.) eller ved at klikke på det. Der er ingen grænse for antallet af assets; størrelsesgrænsen pr. asset er 2 GB.
6. Sæt flueben ved Markér som pre-release for release candidates, betaversioner eller andet, der ikke er klar til almindelig brug. Pre-releases vises for sig i listen over releases og er ikke med i markeringen af “seneste release”.
7. Klik på Udgiv udgivelse for at offentliggøre den med det samme, eller Gem kladde for at gøre den færdig senere. Kladder er kun synlige for organisationens ejere og medlemmer med Write- eller Admin-adgang til repositoriet.

Opret en release fra et workflow

Automatisér releases ved at udløse dem på pushede tags. Det er standardmønsteret for projekter, der bygger binære filer i CI og vil vedhæfte dem til releasen automatisk.

on:
  push:
    tags:
      - 'v*'

jobs:
  release:
    runs-on: fremforge
    steps:
      - uses: actions/checkout@v4

      - name: Build
        run: make build

      - name: Create release
        uses: https://code.forgejo.org/actions/forgejo-release@v2
        with:
          direction: upload
          release-dir: dist/
          token: ${{ secrets.GITHUB_TOKEN }}

secrets.GITHUB_TOKEN er et indbygget token, som automatisk er tilgængeligt for alle workflow-jobs. Det er afgrænset til det aktuelle repository og har skriveadgang til releases i det repository. Der kræves ingen opsætning: fremforge stiller det til rådighed, når jobbet starter, og det udløber, når jobbet slutter.

Handlingen forgejo-release med direction: upload opretter releasen (hvis den ikke allerede findes for tagget) og uploader hver fil fra dist/ som et release-asset.

Upload af assets fra et workflow: via API’et

For fuld kontrol over oprettelsen af releasen og upload af assets kan du kalde API’et direkte fra et workflow:

# Create the release
RELEASE_ID=$(curl -sSf \
  -H "Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}" \
  -H "Content-Type: application/json" \
  -d "{\"tag_name\":\"${{ github.ref_name }}\",\"name\":\"${{ github.ref_name }}\"}" \
  https://frem.sh/api/v1/repos/${{ github.repository }}/releases \
  | jq -r '.id')

# Upload an asset
curl -sSf \
  -H "Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}" \
  -H "Content-Type: application/octet-stream" \
  --data-binary @dist/myapp-linux-amd64 \
  "https://frem.sh/api/v1/repos/${{ github.repository }}/releases/${RELEASE_ID}/assets?name=myapp-linux-amd64"

Fuld API-reference: POST /repos/{owner}/{repo}/releases i REST API-dokumentationen.

Download af release-assets

Offentlige repositories: release-assets er offentligt tilgængelige uden godkendelse. Download direkte fra den asset-URL, der vises på siden med releases.

Private repositories: der kræves et personligt adgangstoken (PAT) med omfanget repo.

curl -L \
  -H "Authorization: Bearer <PAT>" \
  https://frem.sh/<org>/<repo>/releases/download/<tag>/<asset-filename>

Semantisk versionering

Brug tagnavne på formen vMAJOR.MINOR.PATCH. Konsekvent versionering lader værktøjer og afhængighedsstyring finde den “seneste” release korrekt og gør siden med releases lettere at læse for mennesker.

Identifikatorer for pre-releases følger SemVer-konventionen: v1.2.0-rc.1, v2.0.0-beta.3. Markér dem som pre-releases i brugerfladen, eller sæt "prerelease": true i API-kaldets body.

Sletning af en release

1. Gå til Repository → Udgivelser.
2. Find releasen, og klik på Edit.
3. Rul ned til bunden, og klik på Delete release.

Når du sletter en release, fjernes release-posten og alle dens vedhæftede assets. Det underliggende Git-tag slettes ikke af denne handling. For også at slette tagget skal du gå til Repository → Tags og slette det derfra eller køre git push origin --delete <tag> fra en lokal klon.

Releases og SBOM’er

Platformen genererer en SBOM for hvert release-tag og vedhæfter den som et release-asset (f.eks. sbom.spdx.json). Generering af SBOM’er er slået til som standard; der er intet at slå til. Både SPDX 2.3- og CycloneDX 1.6-formatet produceres.

Se Sikkerhed og forsyningskæde for den fulde konfiguration af pipelinen og detaljer om SLSA-provenance.

Releases og pakkeregistret

Releases og pakkeregistret tjener forskellige formål:

Container-images og pakker til sprogøkosystemer har deres egne mekanismer til versionering og opdagelse (image-tags, npm install, mvn dependency:resolve). Brug pakkeregistret til dem, så brugerne kan hente dem direkte med standardværktøjer. Releases er til artefakter, som mennesker eller scripts downloader udtrykkeligt.

Krydshenvisninger

• Pakkeregistret: container-images, npm-, Maven- og PyPI-pakker
• Sikkerhed og forsyningskæde: generering af SBOM’er, scanning af containere, SLSA-provenance
• API: reference for releases i REST API’et
• CI-runners: runner-labels og rettighederne for GITHUB_TOKEN