Hoppa till huvudinnehållet

Issues och pull requests

Issues och PR:er i fremforge är vanliga Forgejo-funktioner. Forgejos dokumentation är referensen för hela funktionsuppsättningen. Den här sidan beskriver fremforge-specifika policyer och integrationer.

Granskningsloggning

Varje statusändring på en issue eller PR (öppna, stänga, öppna igen, ändrad etikett, ändrad tilldelning, inskickad granskning, merge) registreras i organisationens granskningslogg. Posterna i granskningsloggen innehåller aktören, tidsstämpeln, repot och åtgärden. Du når den under Organisationens administration → Granskningslogg eller via API:t.

Merge-grindar för PR:er och branchskydd

PR:er till skyddade brancher måste uppfylla alla konfigurerade regler för branchskydd innan merge-knappen aktiveras. Se Organisationens administration för hur reglerna konfigureras.

Tillämpa granskningsförslag

Forgejo renderar kodblock av typen ```suggestion i granskningskommentarer på PR:er. fremforge lägger till en knapp Apply suggestion ovanpå, med samma upplevelse som i GHEC. Klicka på den på en förslagskommentar så fogas den föreslagna koden in i filen på PR:ens head-commit, tillskriven den användare som klickade.

Så fungerar det:

  1. Knappen visas på varje granskningskommentar som innehåller ett kodblock av typen ```suggestion. Förslag på en rad och på flera rader fungerar båda.
  2. Användaren som tillämpar förslaget måste ha behörigheten write eller admin i repot. Medarbetare med enbart läsbehörighet ser inte knappen.
  3. fremforge kontrollerar att PR:en fortfarande är öppen och att head-SHA:n stämmer med den SHA som gällde när förslaget renderades. Om någon har force-pushat till PR:en efter att förslaget renderades misslyckas tillämpningen med 409 och användaren ombeds uppdatera sidan. Det hindrar ett inaktuellt förslag från att skriva över nyare arbete.
  4. Committen skrivs i den tillämpande användarens namn (inte ett tjänstekonto i fremforge), precis som i GHEC.
  5. Åtgärden registreras i organisationens granskningslogg som pr.suggestion.applied med PR-numret, filsökvägen, radintervallet och granskningskommentarens id.

Att markera konversationen som löst efter tillämpningen är ett manuellt steg (klicka på Resolve i Forgejos granskningsgränssnitt). fremforge löser inte konversationen automatiskt, eftersom Forgejos endpoint för att lösa och dess modell för granskningstrådar skiljer sig subtilt från GitHubs, och vi lovar hellre för lite än för mycket här.

Automatisk merge

PR:er kan ställas in på automatisk merge när alla obligatoriska kontroller går igenom. Slå på det på PR-nivå: klicka på listrutan bredvid Merge → Enable auto-merge. Välj merge-strategi (merge-commit, squash, rebase).

Att pusha nya commits till PR:en avbryter inte den automatiska mergen. PR:en förblir schemalagd och mergas när de obligatoriska kontrollerna går igenom på den nya head-committen; resultat från en tidigare commit räknas inte. Det gäller lika på brancher med och utan merge-kö. Om regeln för branchskydd avfärdar inaktuella godkännanden rensar en push också befintliga godkännanden, och PR:en väntar på ett nytt innan den mergas.

För att hindra en schemalagd PR från att mergas, till exempel innan du pushar en ändring som du fortfarande vill granska, avbryter du den automatiska mergen på PR:en eller anropar DELETE /api/v1/repos/{owner}/{repo}/pulls/{index}/merge. Slår du på den igen senare schemaläggs mergen på nytt.

Merge-kö

En skyddad branch kan använda en merge-kö (inställningen merge_queue i branchskyddsregeln). Med kön påslagen hamnar PR:en i kön när du slår på automatisk merge, och kön testar den i en merge-grupp: målbranchen, plus PR:erna före den i kön, plus den här PR:en. Arbetsflöden som triggas av merge_group körs på den committen och rapporterar statusar av typen … (merge_group). En obligatorisk kontroll X (pull_request) uppfylls av motsvarande resultat X (merge_group), så lägg till merge_group bland triggarna för de arbetsflöden som står bakom dina obligatoriska kontroller.

Vilket bygge som räknas medan en PR står i kö

  • Merge-gruppens körning är PR:ens bygge. När PR:en går in i en merge-grupp avbryts dess pågående pull_request-körningar av varje arbetsflöde som också triggas av merge_group, så att samma arbetsflöde inte byggs två gånger. På PR:en visar de kontrollerna Superseded by the merge queue och tar merge-gruppens resultat.
  • Arbetsflöden utan merge_group-trigger fortsätter att köras på PR:en, och deras resultat räknas som förut. Ett jobb som merge-gruppen hoppar över (till exempel med ett if: som utesluter merge_group) ersätter inte heller PR:ens egen kontroll; det är PR:ens egen körning som avgör den.
  • När PR:en lämnar kön kommer de vanliga kontrollerna tillbaka. Om merge-gruppen misslyckas och PR:en tas bort ur kön, eller om den automatiska mergen avbryts, körs de avbrutna pull_request-körningarna igen på PR:ens commit. En ny push ger den nya committen egna pull_request-körningar, som alltid.
  • En push tar en köad PR ur kön, men inte ur automatisk merge. PR:en behåller sin automatiska merge och ställer sig sist i kön igen när kontrollerna går igenom på den nya committen. Avbryt den automatiska mergen om PR:en inte ska mergas.
  • En misslyckad merge-grupp mergar aldrig PR:en. PR:ens status fremforge/merge-queue visar Merge group failed — removed from the merge queue, en kommentar på PR:en förklarar varför, och den misslyckade körningen finns i repots Actions-lista som en merge_group-körning.

När kön avbryter automatisk merge

Om kön tar bort en PR och inget skulle föra tillbaka den av sig själv kan kön också avbryta PR:ens automatiska merge. Då mergar en senare push som gör kontrollerna gröna inte PR:en innan någon har tittat på den igen. Det gäller när:

  • en av PR:ens egna obligatoriska kontroller misslyckas medan den står i kö;
  • dess merge-grupp misslyckas, får timeout eller hamnar i konflikt med PR:erna före den, efter att de automatiska omförsöken när main flyttas har förbrukats;
  • dess egna kontroller ligger kvar som väntande efter köns timeout för andra gången;
  • kön inte kan döpa om en av dess nya migreringar så att de hamnar i ordning (se opt-in-filen .forgejo/merge-queue-restamp).

En PR som ändå kommer att ställa sig i kön igen av sig själv behåller sin automatiska merge: medan ett omförsök väntar, efter en push, som utkast eller efter att ha förlorat sina godkännanden. Detsamma gäller en PR vars automatiska merge slogs på av en bot som Renovate. Avbrottet visas på PR:en som auto merge cancelled av forgejo-actions. En kommentar förklarar varför, och statusen fremforge/merge-queue slutar med Auto-merge cancelled.

Så slår du på den igen: åtgärda det som tog bort PR:en och slå sedan på automatisk merge igen. Använd knappen Auto merge when checks succeed på PR:en, eller API:t:

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 sedan in i kön när dess egna kontroller går igenom.

Inställningen. merge_queue_disarm_on_removal i branchskyddsregeln är default, on eller off. Ställ in den med API:t för branchskydd (PATCH /api/v1/repos/<org>/<repo>/branch_protections/<rule>). merge_queue_disarm_on_removal_effective i svaret anger om den gäller. För kundorganisationer betyder default för närvarande off, så den automatiska mergen överlever en borttagning som förut. Sätt on för att slå på det för ett repo.

Prioritet i kön

Kön testar PR:er i den ordning de gick in. För att flytta fram en PR, till exempel en rättning av en trasig main eller en hotfix, ger du den hög prioritet. En PR med hög prioritet går före varje PR med normal prioritet som ännu inte ingår i en merge-grupp. Den stoppar eller bygger aldrig om en merge-grupp som redan körs, så den väntar på de grupper som körs och går sedan härnäst. Två PR:er med hög prioritet behåller den ordning de gick in i.

Ställ in prioriteten när du slår på automatisk merge, eller senare medan 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å samma sökväg visar PR:ens prioritet, vem som satte den, dess plats i kön och köns längd. DELETE återställer den till normal.

  • Vem kan sätta den: alla som kan merga PR:en, det vill säga skrivbehörighet till repot plus en plats på branchens tillåtelselista för merge om regeln har en sådan. Alla andra får 403.
  • Den hör till den automatiska mergen. Att avbryta den automatiska mergen, eller slå på den igen, återställer PR:en till normal prioritet. Att sätta en prioritet på en PR utan automatisk merge ger svaret 409.
  • Varje ändring registreras. En kommentar på PR:en anger vem som ändrade prioriteten, från vad till vad, och skälet om ett sådant angavs (upp till 200 tecken).

Använd hög prioritet för den PR som andra väntar på, inte som standard. När varje PR har hög prioritet går kön i ankomstordning igen.

Merge-strategier

Merge-commit, squash-merge och rebase-merge finns alla per repo. Välj tillåtna strategier och standarden under Repot → Inställningar → Enheter → Ändringsförfrågningar (Sammanfogningsstilar, Standard sammanfogningsstil). Organisationsägare ställer in standardstrategin för nya repon under Organisationens administration → Säkerhet → Policyer → Repo-regler (Standardmetod för sammanslagning); varje repo kan åsidosätta den.

Ett nytt repo tar bort en pull requests branch när den mergas och använder squash-merge som standard. fremforge ställer in båda när repot skapas, utifrån organisationens baslinje under Org › Repon (/<org>/_admin/repos-overview#org-baseline), där en organisationsägare kan ändra dem för repon som skapas från och med då. Befintliga repon behåller sin egen inställning (Repot → Inställningar), och en branch vars pull request mergades tidigare lämnas orörd.

Signerade commits vid merge

Om signerade commits krävs på en branch signeras merge-committen av den användare som utför mergen, med användarens registrerade SSH- eller GPG-signeringsnyckel. Se Säkerhet och leveranskedja.

Referenser till issues och PR:er i CI

Arbetsflödeskörningar länkas till den PR som triggade dem. Från en PR klickar du på fliken Checks för att se alla arbetsflödeskörningar för PR:ens head-commit. Från en arbetsflödeskörning länkas den triggande PR:en i körningens sammanfattning.

Referenser mellan repon

Referera till issues och PR:er i andra repon med hela sökvägen: <org>/<repo>#<number> (t.ex. acme/backend#42). Referenser mellan repon skapar en länkad omnämning i båda issuerna.

Stänga issues via en PR

Använd nyckelord i PR:ens beskrivning eller i commits: Closes #42, Fixes #42, Resolves #42. Den refererade issuen stängs automatiskt när PR:en mergas till standardbranchen. För andra brancher stängs issuen när den branchen blir repots standardbranch.

Påminnelser om förfallodatum

fremforge mejlar dig om issues med ett förfallodatum, på samma sätt som GitLab. Forgejo lagrar en issues förfallodatum men skickar aldrig något om det.

  • Dagen innan en issue förfaller får de tilldelade en påminnelse. Om ingen är tilldelad får den som öppnade issuen påminnelsen.
  • När den har förfallit upprepas påminnelsen högst en gång i veckan, i upp till fyra veckor efter förfallodatumet.
  • Högst ett mejl om dagen. Allt som förfaller i morgon och allt som har förfallit samlas i ett mejl med två avsnitt: Förfaller i morgon och Förfallna. Varje post länkar till issuen och visar dess förfallodatum.
  • Vilka issues: öppna issues, inte pull requests, i dina organisationers repon. Stängda issues, arkiverade repon och repon i ett personligt namnutrymme ingår inte.
  • Tidpunkt: mejlet skickas 05:15 UTC (07:15 i Köpenhamn på sommaren, 06:15 på vintern). “I morgon” är nästa kalenderdag i Köpenhamn. Förfallodatumet är det datum som Forgejo visar på issuen.
  • Åtkomst: du får bara påminnelser om repon som du fortfarande kan läsa när mejlet skickas. Om du förlorar åtkomsten till ett repo efter att ha blivit tilldelad försvinner dess issues ur dina påminnelser.
  • Språk: mejlet är på det språk du har valt i Forgejo, på engelska, danska, tyska, franska, nederländska, norska eller svenska. Andra språk får engelska.
  • Vilka som hoppas över: botar, avaktiverade konton och konton utan verifierad e-postadress.

För att stoppa påminnelserna stänger du av Påminnelser om förfallodatum för issues för en organisation i aviseringsinställningarna, eller använder länken för att avsluta prenumerationen med ett klick längst ned i en påminnelse, som stänger av dem för varje organisation som påminnelsen gällde. Du slår på dem igen i aviseringsinställningarna.

Dataexport

Alla issues och PR:er ingår i organisationens fullständiga dataexportpaket. Se Dataexport.

Korsreferenser