Hotfix-provenance

En hotfix-branch oprettes fra den release, der kører i produktion, og rettelsen hentes over fra standardbranchen. Hotfix-provenance sikrer, at det er alt, der sker på den. På en branch, der matcher dit hotfix-mønster (hotfix/* som standard), skal hver commit være:

1. et git cherry-pick -x af en commit på repositoriets standardbranch;
2. hvis mergede pull request har din fast-track-label (fast-track som standard);
3. og hvis ændring er den samme som kildecommittens.

fremforge kontrollerer hver commit i en pull request til en hotfix-branch og hver commit, der pushes til en, og sætter resultatet som commit-statussen fremforge/hotfix-provenance: success eller failure, der nævner den første commit, der ikke består, og hvorfor. Du kan gøre den til et påkrævet check.

Hotfix-provenance er slået fra som standard. En organisationsejer slår det til via API’et.

Sådan laver du et 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 den commit, som mergen lagde på standardbranchen: squash-committen eller merge-committen (git cherry-pick -x -m 1 <merge>). fremforge finder kildens pull request ud fra den commit. Ved rebase-merges kan kun den sidste commit i en rebaset pull request findes på denne måde.

Hvad der fejler, og hvorfor

Statussen nævner den første commit, der fejler, og antallet af andre. Alle commits er listet i forklaringen.

Sådan afgør fremforge det:

• Hvilke commits der tæller. For en pull request til en hotfix-branch dens egne commits. For et push til en hotfix-branch hver commit på branchen, der ikke er på standardbranchen. Det produktionstag, branchen blev oprettet fra, er på standardbranchen, så det tæller aldrig. Opret hotfix-branches fra en commit på standardbranchen.
• Force-pushes kontrolleres forfra: fremforge ser på hele branchen, aldrig kun på commits fra det seneste push.
• Ændringssammenligningen virker som git patch-id: den sammenligner de linjer, hver commit tilføjer og fjerner, fil for fil, og ser bort fra whitespace, linjenumre og de omgivende linjer. Et cherry-pick ind på en ældre release matcher derfor sin kilde. Du kan slå den fra (diff_check: false).
• En label, der tilføjes efter mergen, tæller. fremforge læser kildepull requestens labels, når den kontrollerer. Tilføjes labelen til en merget pull request, kontrolleres de åbne hotfix-pull requests i det repository igen inden for få sekunder.
• Commits fra bots får ingen undtagelse. En bots backport er et cherry-pick som alle andres.
• Når en pull request er merget. Ved et push tæller den squash- eller merge-commit, som en merget pull request til samme hotfix-branch oprettede, som kontrolleret, forudsat at fremforge/hotfix-provenance bestod på den pull request.

Statussen består aldrig ved en fejl

Hvis fremforge ikke kan gøre kontrollen færdig, for eksempel fordi repositoriet ikke kunne læses i tide (30 sekunder), er statussen pending med besked om det, og den kontrolleres igen inden for 5 minutter. Den er aldrig success for en commit, den ikke kunne kontrollere.

På en branch, der ikke er en hotfix-branch, sætter fremforge intet, medmindre den branchs regel kræver fremforge/hotfix-provenance. Så sætter den success, “Not a hotfix branch”, så ingen pull request venter på den. Det samme gælder et repository, hvor hotfix-provenance er slået fra: “not evaluated”.

fremforge sætter statussen inden for få sekunder, efter at en pull request er åbnet, har fået et push, er redigeret eller har fået nyt mål, og efter et push til en hotfix-branch. Et job hvert 5. minut kontrollerer igen enhver åben hotfix-pull request, hvis status mangler eller er pending eller failure.

Slå det til

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 skal have policy:write; GET på samme sti kræver policy:read. Hver ændring revideres som hotfix_provenance.settings_updated.

Gør det til et påkrævet check

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 repositories, også dem, der oprettes senere. fremforge sætter først statussen på hver åben pull request til en hotfix-branch og tilføjer først derefter fremforge/hotfix-provenance til den branch-regel, der har samme navn som mønstret (for eksempel en regel ved navn hotfix/*), og beholder regelens øvrige checks. En merge fra websiden, API’et eller merge-køen venter derefter på den.

fremforge opretter aldrig en branch-regel. Et repository uden en regel for mønstret vises under unprotected; opret reglen (Indstillinger → Grene), så tilføjer jobbet checket inden for 5 minutter. DELETE på samme sti med samme body fjerner det igen. Tokenet skal have policy:write. Begge revideres, som hotfix_provenance.enforcement_enabled og hotfix_provenance.enforcement_disabled.

Hvorfor en pull request består eller fejler

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

Svaret viser hver commit med, om den bestod, den kildecommit, dens linje nævner, kildens pull request og, for en commit der fejlede, problem og årsagen i ord. Det virker også, mens hotfix-provenance er slået fra, så du kan prøve det på en rigtig pull request først. Tokenet skal have findings:read eller læseadgang til repositoriet.