Hotfix-proveniens

En hotfix-branch opprettes fra releasen som kjører i produksjon, og rettingen hentes over fra standardbranchen. Hotfix-proveniens sørger for at det er alt som skjer på den. På en branch som samsvarer med hotfix-mønsteret ditt (hotfix/* som standard), må hver commit være:

1. et git cherry-pick -x av en commit på repositoryets standardbranch;
2. der den mergede pull requesten har fast-track-etiketten din (fast-track som standard);
3. og der endringen er den samme som i kildecommiten.

fremforge kontrollerer hver commit i en pull request mot en hotfix-branch, og hver commit som pushes til en, og legger inn resultatet som commit-statusen fremforge/hotfix-provenance: success, eller failure som oppgir den første commiten som ikke består, og hvorfor. Du kan gjøre den til en påkrevd sjekk.

Hotfix-proveniens er av som standard. En eier av organisasjonen slår det på via API-et.

Slik lager du en hotfix

# 1. Fix it on the default branch first, through a pull request with the label `fast-track`.
# 2. Cut the hotfix branch from the production tag and push it:
git switch -c hotfix/1.4.2 v1.4.1
git push -u origin hotfix/1.4.2
# 3. Carry the fix over on a branch of its own. -x writes the "(cherry picked from commit ...)" line:
git switch -c backport/login-fix
git cherry-pick -x <the commit the merge put on main>
git push -u origin backport/login-fix
# 4. Open a pull request from backport/login-fix into hotfix/1.4.2.

Cherry-pick commiten som mergen la på standardbranchen: squash-commiten eller merge-commiten (git cherry-pick -x -m 1 <merge>). fremforge finner kildens pull request ut fra den commiten. Ved rebase-merger kan bare den siste commiten i en rebaset pull request finnes på denne måten.

Hva som feiler, og hvorfor

Statusen oppgir den første commiten som feiler, og antallet andre. Alle commits er listet i forklaringen.

Slik avgjør fremforge det:

• Hvilke commits som teller. For en pull request mot en hotfix-branch dens egne commits. For en push til en hotfix-branch hver commit på branchen som ikke er på standardbranchen. Produksjonstaggen branchen ble opprettet fra, er på standardbranchen, så den teller aldri. Opprett hotfix-brancher fra en commit på standardbranchen.
• Force-pusher kontrolleres fra bunnen av: fremforge ser på hele branchen, aldri bare på commitene fra den siste pushen.
• Endringssammenligningen virker som git patch-id: den sammenligner linjene hver commit legger til og fjerner, fil for fil, og ser bort fra mellomrom, linjenumre og de omkringliggende linjene. Et cherry-pick inn på en eldre release samsvarer derfor med kilden sin. Du kan slå den av (diff_check: false).
• En etikett som legges til etter mergen, teller. fremforge leser etikettene på kildens pull request når den kontrollerer. Legges etiketten til på en merget pull request, kontrolleres de åpne hotfix-pull requestene i det repositoryet på nytt innen sekunder.
• Commits fra boter får ikke noe unntak. En bots backport er et cherry-pick som alle andres.
• Etter at en pull request er merget. Ved en push regnes squash- eller merge-commiten som en merget pull request mot samme hotfix-branch opprettet, som kontrollert, forutsatt at fremforge/hotfix-provenance besto på den pull requesten.

Statusen består aldri ved en feil

Hvis fremforge ikke kan fullføre kontrollen, for eksempel fordi repositoryet ikke kunne leses i tide (30 sekunder), er statusen pending med beskjed om det, og den kontrolleres på nytt innen 5 minutter. Den er aldri success for en commit den ikke kunne kontrollere.

På en branch som ikke er en hotfix-branch, legger fremforge ikke inn noe, med mindre regelen for den branchen krever fremforge/hotfix-provenance. Da legger den inn success, «Not a hotfix branch», slik at ingen pull request venter på den. Det samme gjelder et repository der hotfix-proveniens er av: «not evaluated».

fremforge legger inn statusen innen sekunder etter at en pull request åpnes, pushes til, redigeres eller får ny målbranch, og etter en push til en hotfix-branch. En jobb hvert 5. minutt kontrollerer på nytt alle åpne hotfix-pull requests der statusen mangler eller er pending eller failure.

Slå det på

curl -X PUT https://frem.sh/_app/api/v1/orgs/<org>/hotfix-provenance/settings \
  -H "Authorization: Bearer $FREMFORGE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"mode": "on", "branch_pattern": "hotfix/*", "required_label": "fast-track"}'

Tokenet trenger policy:write; GET på samme sti trenger policy:read. Hver endring revideres som hotfix_provenance.settings_updated.

Gjør det til en påkrevd sjekk

curl -X PUT https://frem.sh/_app/api/v1/orgs/<org>/hotfix-provenance/enforcement \
  -H "Authorization: Bearer $FREMFORGE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"repo": "*"}'

repo er et repositorynavn, eller * for alle repositoryer, også de som opprettes senere. fremforge legger først inn statusen på hver åpen pull request mot en hotfix-branch, og først da legger den fremforge/hotfix-provenance til i branchregelen som har samme navn som mønsteret (for eksempel en regel med navnet hotfix/*), og beholder regelens andre sjekker. En merge fra nettsiden, API-et eller merge-køen venter da på den.

fremforge oppretter aldri en branchregel. Et repository uten en regel for mønsteret listes i unprotected; opprett regelen (Innstillinger → Brancher), så legger jobben til sjekken innen 5 minutter. DELETE på samme sti med samme body fjerner den igjen. Tokenet trenger policy:write. Begge revideres, som hotfix_provenance.enforcement_enabled og hotfix_provenance.enforcement_disabled.

Hvorfor en pull request består eller feiler

curl https://frem.sh/_app/api/v1/orgs/<org>/repos/<repo>/pulls/<number>/hotfix-provenance \
  -H "Authorization: Bearer $FREMFORGE_TOKEN"

Svaret lister hver commit med om den besto, kildecommiten linjen dens oppgir, kildens pull request og, for en commit som feilet, problem og årsaken i ord. Det virker også mens hotfix-proveniens er av, så du kan prøve det på en ekte pull request først. Tokenet trenger findings:read, eller lesetilgang til repositoryet.