Hotfix-proveniens

En hotfix-branch skapas från den release som körs i produktion, och rättningen hämtas över från standardbranchen. Hotfix-proveniens ser till att det är allt som händer på den. På en branch som matchar ditt hotfix-mönster (hotfix/* som standard) måste varje commit vara:

1. en git cherry-pick -x av en commit på repots standardbranch;
2. vars mergade pull request har din fast-track-etikett (fast-track som standard);
3. och vars ändring är densamma som källcommittens.

fremforge kontrollerar varje commit i en pull request till en hotfix-branch, och varje commit som pushas till en, och publicerar resultatet som commit-statusen fremforge/hotfix-provenance: success, eller failure som anger den första commit som inte går igenom och varför. Du kan göra den till en obligatorisk kontroll.

Hotfix-proveniens är avstängt som standard. En organisationsägare slår på det via API:t.

Så gör 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.

Gör en cherry-pick av den commit som mergen lade på standardbranchen: squash-committen eller merge-committen (git cherry-pick -x -m 1 <merge>). fremforge hittar källans pull request utifrån den committen. Vid rebase-merges kan bara den sista committen i en rebasad pull request hittas på det här sättet.

Vad som misslyckas, och varför

Statusen anger den första commit som misslyckas och antalet andra. Alla commits listas i förklaringen.

Så avgör fremforge:

• Vilka commits som räknas. För en pull request till en hotfix-branch dess egna commits. För en push till en hotfix-branch varje commit på branchen som inte finns på standardbranchen. Produktionstaggen som branchen skapades från finns på standardbranchen, så den räknas aldrig. Skapa hotfix-brancher från en commit på standardbranchen.
• Force-pushar kontrolleras från början: fremforge tittar på hela branchen, aldrig bara på committarna i den senaste pushen.
• Ändringsjämförelsen fungerar som git patch-id: den jämför de rader som varje commit lägger till och tar bort, fil för fil, och bortser från blanktecken, radnummer och de omgivande raderna. En cherry-pick på en äldre release matchar därför sin källa. Du kan stänga av den (diff_check: false).
• En etikett som läggs till efter mergen räknas. fremforge läser källans pull request-etiketter när den kontrollerar. Läggs etiketten till på en mergad pull request kontrolleras de öppna hotfix-pull requesterna i det repot igen inom några sekunder.
• Commits från bottar får inget undantag. En botts backport är en cherry-pick som alla andras.
• Efter att en pull request har mergats. Vid en push räknas den squash- eller merge-commit som en mergad pull request till samma hotfix-branch skapade som kontrollerad, förutsatt att fremforge/hotfix-provenance gick igenom på den pull requesten.

Statusen går aldrig igenom av misstag

Om fremforge inte kan slutföra kontrollen, till exempel för att repot inte kunde läsas i tid (30 sekunder), är statusen pending med besked om det, och den kontrolleras igen inom 5 minuter. Den är aldrig success för en commit som inte kunde kontrolleras.

På en branch som inte är en hotfix-branch publicerar fremforge ingenting, om inte den branchens regel kräver fremforge/hotfix-provenance. Då publicerar den success, “Not a hotfix branch”, så att ingen pull request väntar på den. Detsamma gäller ett repo där hotfix-proveniens är avstängt: “not evaluated”.

fremforge publicerar statusen inom några sekunder efter att en pull request har öppnats, fått en push, redigerats eller fått en ny målbranch, och efter en push till en hotfix-branch. Ett jobb var 5:e minut kontrollerar igen varje öppen hotfix-pull request vars status saknas eller är pending eller failure.

Slå på det

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"}'

Token behöver policy:write; GET på samma sökväg behöver policy:read. Varje ändring granskningsloggas som hotfix_provenance.settings_updated.

Gör det till en obligatorisk kontroll

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 är ett reponamn, eller * för alla repon, även sådana som skapas senare. fremforge publicerar först statusen på varje öppen pull request till en hotfix-branch, och först därefter läggs fremforge/hotfix-provenance till i den branch-regel som heter som mönstret (till exempel en regel med namnet hotfix/*), och regelns övriga kontroller behålls. En merge från webbsidan, API:t eller merge-kön väntar sedan på den.

fremforge skapar aldrig en branch-regel. Ett repo utan regel för mönstret listas under unprotected; skapa regeln (Inställningar → Grenar), så lägger jobbet till kontrollen inom 5 minuter. DELETE på samma sökväg med samma body tar bort den igen. Token behöver policy:write. Båda granskningsloggas, som hotfix_provenance.enforcement_enabled och hotfix_provenance.enforcement_disabled.

Varför en pull request går igenom eller misslyckas

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

Svaret listar varje commit med om den gick igenom, den källcommit som dess rad anger, källans pull request och, för en commit som misslyckades, problem och skälet i ord. Det fungerar även när hotfix-proveniens är avstängt, så du kan prova det på en riktig pull request först. Token behöver findings:read, eller läsåtkomst till repot.