Gå til hovedinnhold

Issues og pull requests

Issues og PR-er i fremforge er vanlige Forgejo-funksjoner. Forgejo-dokumentasjonen er referansen for hele funksjonssettet. Denne siden dekker policyer og integrasjoner som er spesifikke for fremforge.

Revisjonslogging

Hver tilstandsendring på en issue eller en PR (åpne, lukke, åpne igjen, endre etikett, endre ansvarlig, sende inn gjennomgang, merge) registreres i organisasjonens revisjonslogg. Oppføringene i revisjonsloggen inneholder aktør, tidsstempel, repository og handling. Du finner dem under Organisasjonsadministrasjon → Revisjonslogg eller via API-et.

Merge-sperrer for PR-er og branchbeskyttelse

PR-er mot beskyttede brancher må oppfylle alle konfigurerte regler for branchbeskyttelse før merge-knappen blir aktiv. Se Organisasjonsadministrasjon for oppsett av regler.

Ta i bruk forslag fra gjennomgang

Forgejo viser ```suggestion-kodeblokker i kommentarer i PR-gjennomganger. fremforge legger til en Apply suggestion-knapp som tar i bruk forslaget med ett klikk, med samme brukeropplevelse som GHEC. Klikk på den på en forslagskommentar, så settes den foreslåtte koden inn i filen på PR-ens head-commit, kreditert brukeren som klikket.

Slik virker det:

  1. Knappen vises på hver gjennomgangskommentar som inneholder en ```suggestion-kodeblokk. Forslag på én linje og på flere linjer virker begge.
  2. Brukeren som tar i bruk forslaget, må ha write- eller admin-tilgang til repositoryet. Samarbeidspartnere med bare lesetilgang ser ikke knappen.
  3. fremforge kontrollerer at PR-en fortsatt er åpen og at head-SHA-en stemmer med SHA-en forslaget ble vist mot. Hvis det er force-pushet til PR-en etter at forslaget ble vist, feiler handlingen med 409, og brukeren blir bedt om å laste inn på nytt. Det hindrer at et utdatert forslag overskriver nyere arbeid.
  4. Commiten får brukeren som tok i bruk forslaget, som forfatter (ikke en tjenestekonto i fremforge), nøyaktig som i GHEC.
  5. Handlingen registreres i organisasjonens revisjonslogg som pr.suggestion.applied med PR-nummer, filsti, linjeområde og ID-en til gjennomgangskommentaren.

Å løse samtalen etter at forslaget er tatt i bruk, er et manuelt steg (klikk Resolve i gjennomgangsvisningen i Forgejo). fremforge løser den ikke automatisk, fordi Forgejos resolve-endepunkt og modell for gjennomgangstråder skiller seg litt fra GitHubs, og vi vil heller love for lite enn for mye her.

Automatisk merge

PR-er kan settes til å merges automatisk når alle påkrevde sjekker er grønne. Slå det på for den enkelte PR-en: klikk på nedtrekksmenyen ved siden av Merge → Enable auto-merge. Velg merge-strategi (merge-commit, squash, rebase).

Nye commits som pushes til PR-en, avbryter ikke automatisk merge. PR-en forblir planlagt og merges når de påkrevde sjekkene er grønne på den nye head-commiten; resultater fra en tidligere commit teller ikke. Dette gjelder både på brancher med og uten merge-kø. Hvis regelen for branchbeskyttelse forkaster utdaterte godkjenninger, fjerner en push også eksisterende godkjenninger, og PR-en venter på en ny godkjenning før den merges.

For å hindre at en planlagt PR merges, for eksempel før du pusher en endring du fortsatt vil gjennomgå, avbryter du automatisk merge på PR-en, eller kaller DELETE /api/v1/repos/{owner}/{repo}/pulls/{index}/merge. Slår du det på igjen senere, planlegges merge på nytt.

Merge-kø

En beskyttet branch kan bruke en merge-kø (innstillingen merge_queue i regelen for branchbeskyttelse). Når køen er på, legger automatisk merge PR-en i køen, og køen tester den i en merge-gruppe: målbranchen, pluss PR-ene foran den i køen, pluss denne PR-en. Workflower som utløses av merge_group, kjører på den commiten og rapporterer statuser av typen … (merge_group). En påkrevd sjekk X (pull_request) oppfylles av det tilsvarende resultatet X (merge_group), så legg til merge_group i utløserne for workflowene bak de påkrevde sjekkene dine.

Hvilket bygg som teller mens en PR står i kø

  • Merge-gruppens kjøring er PR-ens bygg. Når PR-en går inn i en merge-gruppe, avbrytes pågående pull_request-kjøringer av hver workflow som også utløses av merge_group, så samme workflow ikke bygger to ganger. På PR-en står det Superseded by the merge queue ved disse sjekkene, og de får merge-gruppens resultat.
  • Workflower uten merge_group-utløser fortsetter å kjøre på PR-en, og resultatene deres teller som før. En jobb som merge-gruppen hopper over (for eksempel med en if: som utelukker merge_group), erstatter heller ikke PR-ens egen sjekk; PR-ens egen kjøring avgjør den.
  • Når PR-en forlater køen, kommer de vanlige sjekkene tilbake. Hvis merge-gruppen feiler og PR-en fjernes fra køen, eller automatisk merge avbrytes, kjøres de avbrutte pull_request-kjøringene på nytt på PR-ens commit. En ny push gir den nye commiten egne pull_request-kjøringer, som alltid.
  • En push tar en PR i kø ut av køen, ikke ut av automatisk merge. PR-en beholder automatisk merge og stiller seg bakerst i køen igjen når sjekkene er grønne på den nye commiten. Avbryt automatisk merge hvis den ikke skal merges.
  • En merge-gruppe som feiler, merger aldri PR-en. Statusen fremforge/merge-queue på PR-en viser Merge group failed — removed from the merge queue, en kommentar på PR-en forklarer hvorfor, og den mislykkede kjøringen står i repositoryets Actions-liste som en merge_group-kjøring.

Når køen avbryter automatisk merge

Hvis køen fjerner en PR og ingenting ville ført den tilbake av seg selv, kan den også avbryte PR-ens automatiske merge. Da merger ikke en senere push som gjør sjekkene grønne, PR-en før noen har sett på den igjen. Dette gjelder når:

  • en av PR-ens egne påkrevde sjekker feiler mens den står i kø;
  • merge-gruppen feiler, får tidsavbrudd eller er i konflikt med PR-ene foran den, etter at de automatiske nye forsøkene når main flytter seg, er brukt opp;
  • PR-ens egne sjekker står ventende forbi køens tidsavbrudd for andre gang;
  • køen ikke kan gi en av de nye migreringene et nytt navn i riktig rekkefølge (se tilvalget .forgejo/merge-queue-restamp).

En PR som fortsatt vil komme tilbake av seg selv, beholder automatisk merge: mens et nytt forsøk venter, etter en push, som utkast eller etter at den har mistet godkjenningene sine. Det samme gjør en PR der en bot som Renovate slo på automatisk merge. Avbrytelsen vises på PR-en som auto merge cancelled av forgejo-actions. En kommentar forklarer hvorfor, og statusen fremforge/merge-queue slutter med Auto-merge cancelled.

Slik klargjør du igjen: rett det som fjernet PR-en, og slå deretter på automatisk merge igjen. Bruk 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 går så inn i køen når de egne sjekkene er grønne.

Innstillingen. merge_queue_disarm_on_removal i regelen for branchbeskyttelse er default, on eller off. Sett den med API-et for branchbeskyttelse (PATCH /api/v1/repos/<org>/<repo>/branch_protections/<rule>). merge_queue_disarm_on_removal_effective i svaret forteller om den gjelder. For kundeorganisasjoner betyr default foreløpig off, så klargjøringen overlever en fjerning som før. Sett on for å slå det på for et repository.

Prioritet i køen

Køen tester PR-er i den rekkefølgen de kom inn. For å flytte én PR fremover, for eksempel en rettelse for en ødelagt main eller en hasterettelse, gir du den high prioritet. En PR med høy prioritet går foran alle vanlige PR-er som ennå ikke er i en merge-gruppe. Den stopper eller bygger aldri om en merge-gruppe som allerede kjører, så den venter på gruppene som kjører, og går deretter. To PR-er med høy prioritet beholder rekkefølgen de kom inn i.

Sett prioriteten når du slår på automatisk merge, 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 som satte den, posisjonen i køen og køens lengde. DELETE setter den tilbake til normal.

  • Hvem kan sette den: alle som kan merge PR-en, det vil si skrivetilgang til repositoryet, og i tillegg en oppføring på branchens tillatelsesliste for merge hvis regelen har en. Alle andre får 403.
  • Den hører til den automatiske mergen. Når automatisk merge avbrytes eller slås på igjen, settes PR-en tilbake til normal. Å sette en prioritet på en PR uten automatisk merge gir 409.
  • Hver endring registreres. En kommentar på PR-en forteller hvem som endret prioriteten, fra hva til hva, og begrunnelsen hvis en ble oppgitt (opptil 200 tegn).

Bruk høy prioritet for PR-en som andre venter på, ikke som standard. Når alle PR-er har høy prioritet, går køen i innkomstrekkefølge igjen.

Merge-strategier

Merge-commit, squash-merge og rebase-merge er alle tilgjengelige per repository. Velg hvilke strategier som er tillatt, og standarden, under Repository → Innstillinger → Enheter → Pull requests (Merge-stiler, Standard merge-stil). Eiere av organisasjonen setter standard merge-metode for nye repositoryer under Organisasjonsadministrasjon → Sikkerhet → Policyer → Regler for repositoryer (Standard merge-metode); hvert repository kan overstyre den.

Et nytt repository sletter branchen til en pull request når den merges, og bruker squash-merge som standard. fremforge setter begge deler når repositoryet opprettes, ut fra organisasjonens grunnoppsett under Organisasjon › Repositoryer (/<org>/_admin/repos-overview#org-baseline), der en eier av organisasjonen kan endre dem for repositoryer som opprettes fra da av. Eksisterende repositoryer beholder sin egen innstilling (Repository → Innstillinger), og en branch der pull requesten ble merget tidligere, blir stående.

Signerte commits ved merge

Hvis signerte commits er påkrevd på en branch, signeres merge-commiten av brukeren som utfører mergen, med den registrerte SSH- eller GPG-signeringsnøkkelen. Se Sikkerhet og forsyningskjede.

Referanser til issues og PR-er i CI

Workflow-kjøringer er koblet til PR-en som utløste dem. Fra en PR klikker du på fanen Checks for å se alle workflow-kjøringer for PR-ens head-commit. Fra en workflow-kjøring er den utløsende PR-en lenket i oppsummeringen av kjøringen.

Referanser på tvers av repositoryer

Referer til issues og PR-er på tvers av repositoryer med full slug: <org>/<repo>#<number> (f.eks. acme/backend#42). Referanser på tvers av repositoryer lager en lenket omtale i begge issues.

Lukke issues via PR

Bruk nøkkelord i PR-teksten eller i commits: Closes #42, Fixes #42, Resolves #42. Den refererte issuen lukkes automatisk når PR-en merges inn i standardbranchen. For andre brancher lukkes issuen når den branchen settes som repositoryets standardbranch.

Påminnelser om forfallsdato

fremforge sender deg e-post om issues med forfallsdato, slik GitLab gjør. Forgejo lagrer forfallsdatoen til en issue, men sender aldri noe om den.

  • Dagen før en issue forfaller, får de ansvarlige en påminnelse. Hvis ingen er tildelt, får personen som opprettet issuen den.
  • Når den har forfalt, gjentas påminnelsen høyst én gang i uken, i opptil fire uker etter forfallsdatoen.
  • Høyst én e-post om dagen. Alt som forfaller i morgen og alt som har forfalt, samles i én e-post, i to deler: Due tomorrow og Forfalt. Hvert punkt lenker til issuen og viser forfallsdatoen.
  • Hvilke issues: åpne issues, ikke pull requests, i organisasjonenes repositoryer. Lukkede issues, arkiverte repositoryer og repositoryer i et personlig navnerom er ikke med.
  • Tidspunkt: e-posten sendes kl. 05:15 UTC (07:15 i København om sommeren, 06:15 om vinteren). «I morgen» er neste kalenderdag i København. Forfallsdatoen er datoen Forgejo viser på issuen.
  • Tilgang: du får bare påminnelser om repositoryer du fortsatt kan lese når e-posten sendes. Hvis du mister tilgangen til et repository etter at du ble tildelt, faller issuene der ut av påminnelsene dine.
  • Språk: e-posten er på språket du har valgt i Forgejo, på engelsk, dansk, tysk, fransk, nederlandsk, norsk eller svensk. Andre språk får engelsk.
  • Hvem som hoppes over: boter, deaktiverte kontoer og kontoer uten bekreftet e-postadresse.

For å stoppe påminnelsene slår du av Påminnelser om forfallsdato for issues for en organisasjon i varslingsinnstillingene, eller bruker avmeldingslenken nederst i en påminnelse. Den slår dem av for alle organisasjonene påminnelsen gjaldt. Du slår dem på igjen i varslingsinnstillingene.

Dataeksport

Alle issues og PR-er er med i den fullstendige dataeksportpakken for organisasjonen. Se Dataeksport.

Se også