Gå til hovedindhold

Issues og pull requests

Issues og PR’er i fremforge er almindelige Forgejo-funktioner. Forgejos dokumentation er referencen for hele funktionssættet. Denne side dækker fremforge-specifikke politikker og integrationer.

Revisionslogning

Hver tilstandsændring på et issue eller en PR (åbn, luk, genåbn, ændring af labels, ændring af ansvarlig, indsendt review, merge) registreres i organisationens revisionslog. Posterne i revisionsloggen indeholder aktøren, tidspunktet, repositoriet og handlingen. Du finder dem under Administration → Revisionslog eller via API’et.

Merge-gates for PR’er og branchbeskyttelse

PR’er til beskyttede branches skal opfylde alle opsatte regler for branchbeskyttelse, før merge-knappen bliver aktiv. Se Organisationsadministration for opsætning af reglerne.

Anvend forslag fra reviews

Forgejo viser ```suggestion-kodeblokke i reviewkommentarer på PR’er. fremforge lægger en knap til ét klik, Apply suggestion, ovenpå: samme brugeroplevelse som i GHEC. Klik på den på en kommentar med et forslag, og den foreslåede kode flettes ind i filen på PR’ens head-commit, tilskrevet den bruger, der klikkede.

Sådan virker det:

  1. Knappen vises på hver reviewkommentar, der indeholder en ```suggestion-kodeblok. Forslag på én linje og på flere linjer virker begge.
  2. Brugeren, der anvender forslaget, skal have write- eller admin-rettighed på repositoriet. Samarbejdspartnere med kun læseadgang ser ikke knappen.
  3. fremforge kontrollerer, at PR’en stadig er åben, og at head-SHA’en svarer til den SHA, forslaget blev vist med. Hvis der er force-pushet til PR’en, efter forslaget blev vist, fejler anvendelsen med 409, og brugeren bliver bedt om at genindlæse. Det forhindrer, at et forældet forslag overskriver nyere arbejde.
  4. Commit’en får den anvendende bruger som forfatter (ikke en servicekonto i fremforge), præcis som i GHEC.
  5. Handlingen registreres i organisationens revisionslog som pr.suggestion.applied med PR-nummer, filsti, linjeinterval og id på reviewkommentaren.

At markere samtalen som løst efter anvendelsen er et manuelt trin (klik på Resolve i Forgejos review-brugerflade). fremforge løser den ikke automatisk, fordi Forgejos resolve-endpoint og model for reviewtråde afviger subtilt fra GitHubs, og vi vil hellere love for lidt her.

Auto-merge

PR’er kan sættes til auto-merge, når alle påkrævede checks består. Slå det til på PR-niveau: klik på rullemenuen ved siden af Merge → Enable auto-merge. Vælg merge-strategien (merge commit, squash, rebase).

Nye commits pushet til PR’en annullerer ikke auto-merge. PR’en forbliver planlagt og merges, når de påkrævede checks består på den nye head-commit; resultater fra en tidligere commit tæller ikke. Det gælder ens for branches med og uden en merge-kø. Hvis reglen for branchbeskyttelse afviser forældede godkendelser, rydder et push også eksisterende godkendelser, og PR’en venter på en ny, før den merges.

Vil du forhindre en planlagt PR i at blive merget, for eksempel før du pusher en ændring, du stadig vil reviewe, så annullér auto-merge på PR’en, eller kald DELETE /api/v1/repos/{owner}/{repo}/pulls/{index}/merge. Slår du det til igen senere, planlægges merge forfra.

Merge-kø

En beskyttet branch kan bruge en merge-kø (indstillingen merge_queue i dens regel for branchbeskyttelse). Med køen slået til sætter auto-merge PR’en i køen, og køen tester den i en merge-gruppe: målbranchen plus de PR’er, der står foran den i køen, plus denne PR. Workflows, der udløses af merge_group, kører på den commit og rapporterer … (merge_group)-statusser. Et påkrævet X (pull_request)-check opfyldes af det tilsvarende X (merge_group)-resultat, så tilføj merge_group til triggerne på de workflows, der ligger bag dine påkrævede checks.

Hvilket build der tæller, mens en PR står i kø

  • Merge-gruppens kørsel er PR’ens build. Når PR’en kommer ind i en merge-gruppe, annulleres dens igangværende pull_request-kørsler af alle workflows, der også udløses af merge_group, så det samme workflow ikke bygger to gange. På PR’en står der ved de checks Superseded by the merge queue, og de får merge-gruppens resultat.
  • Workflows uden en merge_group-trigger bliver ved med at køre på PR’en, og deres resultater tæller som før. Et job, som merge-gruppen springer over (for eksempel med en if:, der udelukker merge_group), træder heller ikke i stedet for PR’ens eget check; det er PR’ens egen kørsel, der afgør det.
  • Når PR’en forlader køen, kommer de normale checks tilbage. Hvis merge-gruppen fejler og PR’en fjernes fra køen, eller auto-merge annulleres, køres de annullerede pull_request-kørsler igen på PR’ens commit. Et nyt push giver som altid den nye commit sine egne pull_request-kørsler.
  • Et push tager en PR i kø ud af køen, ikke ud af auto-merge. PR’en beholder sin auto-merge og stiller sig bagerst i køen igen, når dens checks består på den nye commit. Annullér auto-merge, hvis den ikke skal merges.
  • En fejlet merge-gruppe merger aldrig PR’en. PR’ens fremforge/merge-queue-status viser Merge group failed — removed from the merge queue, en kommentar på PR’en forklarer hvorfor, og den fejlede kørsel står i repositoriets Actions-liste som en merge_group-kørsel.

Når køen annullerer auto-merge

Hvis køen fjerner en PR, og intet ville bringe den tilbage af sig selv, kan den også annullere PR’ens auto-merge. Så merger et senere push, der gør checks grønne, ikke PR’en, før nogen har kigget på den igen. Det gælder, når:

  • et af PR’ens egne påkrævede checks fejler, mens den står i kø;
  • dens merge-gruppe fejler, får timeout eller er i konflikt med de PR’er, der står foran den, efter at de automatiske genforsøg, når main flytter sig, er brugt op;
  • dens egne checks for anden gang forbliver ventende ud over køens timeout;
  • køen ikke kan omdøbe en af dens nye migreringer, så de kommer i rækkefølge (se tilvalget .forgejo/merge-queue-restamp).

En PR, der alligevel stiller sig i køen igen af sig selv, beholder sin auto-merge: mens et genforsøg venter, efter et push, som kladde, eller efter at have mistet sine godkendelser. Det samme gør en PR, hvor en bot som Renovate har slået auto-merge til. Annulleringen vises på PR’en som auto merge cancelled af forgejo-actions. En kommentar forklarer hvorfor, og fremforge/merge-queue-statussen slutter med Auto-merge cancelled.

Sådan slår du det til igen: ret det, der fjernede PR’en, og slå så auto-merge til igen. Brug knappen Auto merge when checks succeed på PR’en eller API’et:

curl -X POST -H "Authorization: token $TOKEN" -H "Content-Type: application/json" \
  https://frem.sh/api/v1/repos/<org>/<repo>/pulls/<number>/merge \
  -d '{"Do":"squash","merge_when_checks_succeed":true}'

PR’en kommer så i køen, når dens egne checks består.

Indstillingen. merge_queue_disarm_on_removal i reglen for branchbeskyttelse er default, on eller off. Sæt den med API’et for branchbeskyttelse (PATCH /api/v1/repos/<org>/<repo>/branch_protections/<rule>). merge_queue_disarm_on_removal_effective i svaret fortæller, om den gælder. For kundeorganisationer betyder default i øjeblikket off, så auto-merge overlever en fjernelse som før. Sæt on for at tilvælge det for et repository.

Prioritet i køen

Køen tester PR’er i den rækkefølge, de kom ind. Vil du flytte én PR frem, for eksempel en rettelse til en rød main eller et hotfix, så giv den prioriteten high. En high-PR går foran alle normale PR’er, der endnu ikke er i en merge-gruppe. Den stopper eller genbygger aldrig en merge-gruppe, der allerede kører, så den venter på de grupper, der kører, og er den næste. To high-PR’er beholder den rækkefølge, de kom ind i.

Sæt prioriteten, når du slår auto-merge til, eller senere, mens PR’en står i kø:

# when enabling auto-merge
curl -X POST -H "Authorization: token $TOKEN" -H "Content-Type: application/json" \
  https://frem.sh/api/v1/repos/<org>/<repo>/pulls/<number>/merge \
  -d '{"Do":"squash","merge_when_checks_succeed":true,"merge_queue_priority":"high"}'

# on a PR that already has auto-merge
curl -X PUT -H "Authorization: token $TOKEN" -H "Content-Type: application/json" \
  https://frem.sh/api/v1/repos/<org>/<repo>/pulls/<number>/merge-queue/priority \
  -d '{"priority":"high","reason":"fixes the red main"}'

GET på samme sti viser PR’ens prioritet, hvem der satte den, dens plads i køen og køens længde. DELETE sætter den tilbage til normal.

  • Hvem kan sætte den: alle, der kan merge PR’en, dvs. skriveadgang til repositoriet plus en plads på branchens merge-tilladelsesliste, hvis reglen har en. Alle andre får 403.
  • Den hører til auto-merge. Annullerer du auto-merge eller slår det til igen, sættes PR’en tilbage til normal. At sætte en prioritet på en PR uden auto-merge giver 409.
  • Hver ændring registreres. En kommentar på PR’en fortæller, hvem der ændrede prioriteten, fra hvad til hvad, og årsagen, hvis der blev givet en (op til 200 tegn).

Brug høj prioritet til den PR, andre venter på, ikke som standard. Når alle PR’er er high, går køen igen i den rækkefølge, de kom ind.

Merge-strategier

Merge commit, squash merge og rebase merge er alle tilgængelige pr. repository. Vælg de tilladte strategier og standarden under Repository → Indstillinger → Enheder → Pull-anmodninger (Flettestil, Standard flettestil). Organisationens ejere sætter standardstrategien for nye repositories under Administration → Sikkerhed → Politikker → Repository-regler (Standard fletningsmetode); hvert repository kan tilsidesætte den.

Et nyt repository sletter en pull requests branch, når den merges, og bruger squash-merge som standard. fremforge sætter begge dele, når repositoriet oprettes, ud fra organisationens udgangspunkt under Org › Repositorier (/<org>/_admin/repos-overview#org-baseline), hvor en ejer af organisationen kan ændre dem for repositories, der oprettes fra da af. Eksisterende repositories beholder deres egen indstilling (Repository → Indstillinger), og en branch, hvis pull request blev merget tidligere, røres ikke.

Signerede commits ved merge

Hvis signerede commits er påkrævet på en branch, signeres merge-commit’en af den bruger, der udfører merge, med vedkommendes registrerede SSH- eller GPG-signeringsnøgle. Se Sikkerhed og forsyningskæde.

Referencer til issues og PR’er i CI

Workflow-kørsler er knyttet til den PR, der udløste dem. Fra en PR klikker du på fanen Checks for at se alle workflow-kørsler for PR’ens head-commit. Fra en workflow-kørsel er den udløsende PR linket i kørslens oversigt.

Referencer på tværs af repositories

Henvis til issues og PR’er på tværs af repositories med det fulde slug: <org>/<repo>#<number> (f.eks. acme/backend#42). Referencer på tværs af repositories opretter en linket omtale i begge issues.

Luk issues via en PR

Brug nøgleord i PR’ens beskrivelse eller i commits: Closes #42, Fixes #42, Resolves #42. Det refererede issue lukkes automatisk, når PR’en merges ind i standardbranchen. For andre branches lukkes issuet, når den branch bliver sat som repositoriets standardbranch.

Påmindelser om forfaldsdatoer

fremforge sender dig e-mails om issues med en forfaldsdato, ligesom GitLab gør. Forgejo gemmer et issues forfaldsdato, men sender aldrig noget om den.

  • Dagen før et issue forfalder, får de ansvarlige en påmindelse. Er der ingen ansvarlig, får den person, der oprettede issuet, den.
  • Når det er forfaldent, gentages påmindelsen højst én gang om ugen, i op til fire uger efter forfaldsdatoen.
  • Højst én e-mail om dagen. Alt, der forfalder i morgen, og alt, der er forfaldent, samles i én e-mail i to afsnit: Due tomorrow og Overdue. Hvert punkt linker til issuet og viser dets forfaldsdato.
  • Hvilke issues: åbne issues, ikke pull requests, i dine organisationers repositories. Lukkede issues, arkiverede repositories og repositories i et personligt navnerum er ikke med.
  • Tidspunkt: e-mailen sendes kl. 05:15 UTC (07:15 i København om sommeren, 06:15 om vinteren). “I morgen” er næste kalenderdag i København. Forfaldsdatoen er den dato, Forgejo viser på issuet.
  • Adgang: du får kun påmindelser om repositories, du stadig kan læse, når e-mailen sendes. Mister du adgangen til et repository, efter du er blevet ansvarlig, falder dets issues ud af dine påmindelser.
  • Sprog: e-mailen er på det sprog, du har valgt i Forgejo, på engelsk, dansk, tysk, fransk, nederlandsk, norsk eller svensk. Andre sprog får engelsk.
  • Hvem springes over: bots, deaktiverede konti og konti uden en bekræftet e-mailadresse.

Vil du stoppe påmindelserne, så slå Påmindelser om forfaldsdatoer på issues fra for en organisation i notifikationsindstillingerne, eller brug linket til afmelding med ét klik nederst i en påmindelse, som slår dem fra for alle de organisationer, påmindelsen dækkede. Du slår dem til igen i notifikationsindstillingerne.

Dataeksport

Alle issues og PR’er er med i organisationens fulde dataeksport. Se Fuld dataeksport.

Krydshenvisninger