Skip to main content

Issues and pull requests

Issues and PRs in fremforge are standard Forgejo features. The Forgejo documentation is the reference for the full feature set. This page covers fremforge-specific policies and integrations.

Audit logging

Every state change to an issue or PR (open, close, reopen, label change, assignee change, review submitted, merge) is recorded in the org audit log. Audit log entries include the actor, timestamp, repository, and action. Access at Org admin → Audit log or via the API.

PR merge gates and branch protection

PRs into protected branches must satisfy all configured branch protection rules before the merge button is enabled. See Org admin for rule configuration.

Apply review suggestions

Forgejo renders ```suggestion code blocks inside PR review comments. fremforge layers a one-click Apply suggestion button on top — the same UX as GHEC. Click it on any suggestion comment and the suggested code is spliced into the file at the PR’s head commit, attributed to the user who clicked.

Mechanics:

  1. The button appears on every review comment that contains a ```suggestion code-fence block. Single-line and multi-line suggestions both work.
  2. The applying user must have write or admin permission on the repo. Read-only collaborators don’t see the button.
  3. fremforge verifies the PR is still open and the head SHA matches the suggestion’s render-time SHA. If the PR was force-pushed after the suggestion was rendered, the apply fails with a 409 and the user is asked to refresh — this prevents a stale suggestion from overwriting newer work.
  4. The commit is authored as the applying user (not a fremforge service account), exactly mirroring GHEC behaviour.
  5. The action is captured in the org audit log as pr.suggestion.applied with the PR number, file path, line range, and review-comment id.

Resolving the conversation after applying is a manual step (click Resolve in Forgejo’s review UI) — fremforge does not auto-resolve because Forgejo’s resolve endpoint and review thread model differ subtly from GitHub’s and we’d rather under-promise here.

Auto-merge

PRs can be set to auto-merge when all required checks pass. Enable at the PR level: click the dropdown next to Merge → Enable auto-merge. Select the merge strategy (merge commit, squash, rebase).

Pushing new commits to the PR does not cancel auto-merge. The PR stays scheduled and merges once the required checks pass on the new head commit; results from an earlier commit do not count. This is the same on branches with and without a merge queue. If the branch protection rule dismisses stale approvals, a push also clears existing approvals, and the PR waits for a new one before it merges.

To stop a scheduled PR from merging, for example before pushing a change you still want to review, cancel auto-merge on the PR, or call DELETE /api/v1/repos/{owner}/{repo}/pulls/{index}/merge. Enabling it again later schedules the merge afresh.

Merge queue

A protected branch can use a merge queue (the merge_queue setting of its branch protection rule). With the queue on, enabling auto-merge puts the PR in the queue, and the queue tests it in a merge group: the target branch, plus the PRs ahead of it in the queue, plus this PR. Workflows that trigger on merge_group run on that commit and report … (merge_group) statuses. A required X (pull_request) check is satisfied by the matching X (merge_group) result, so add merge_group to the triggers of the workflows behind your required checks.

Which build counts while a PR is queued

  • The merge group’s run is the PR’s build. When the PR enters a merge group, its in-flight pull_request runs of every workflow that also triggers on merge_group are cancelled, so the same workflow does not build twice. On the PR, those checks read Superseded by the merge queue and take the merge group’s result.
  • Workflows without a merge_group trigger keep running on the PR, and their results count as before. A job that the merge group skips (for example with an if: that excludes merge_group) does not stand in for the PR’s own check either; the PR’s own run decides it.
  • Leaving the queue brings the normal checks back. If the merge group fails and the PR is removed from the queue, or auto-merge is cancelled, the cancelled pull_request runs are run again on the PR’s commit. A new push gives the new commit its own pull_request runs, as always.
  • A push takes a queued PR out of the queue, not out of auto-merge. The PR keeps its auto-merge and rejoins the queue at the back once its checks pass on the new commit. Cancel auto-merge if it should not merge.
  • A failed merge group never merges the PR. The PR’s fremforge/merge-queue status reads Merge group failed — removed from the merge queue, a comment on the PR says why, and the failed run is in the repository’s Actions list as a merge_group run.

Merge strategies

Merge commit, squash merge, and rebase merge are all available per-repository. Set the default strategy at Repository → Settings → Merging. Org owners can restrict which strategies are available at Org admin → Repo defaults → Merging strategy.

Signed commits on merge

If signed commits are required on a branch, the merge commit is signed by the user performing the merge using their registered SSH or GPG signing key. See Security and supply chain.

Issue and PR references in CI

Workflow runs are linked to the PR that triggered them. From a PR, click the Checks tab to see all workflow runs for the PR’s head commit. From a workflow run, the triggering PR is linked in the run summary.

Cross-repository references

Reference issues and PRs across repositories using the full slug: <org>/<repo>#<number> (e.g., acme/backend#42). Cross-repo references create a linked mention in both issues.

Closing issues via PR

Use keywords in the PR body or commits: Closes #42, Fixes #42, Resolves #42. The referenced issue closes automatically when the PR merges into the default branch. For non-default branches, the issue closes when that branch is set as the repository’s default.

Due-date reminders

fremforge emails you about issues with a due date, the way GitLab does. Forgejo stores an issue’s due date but never sends anything about it.

  • The day before an issue is due, its assignees get a reminder. If nobody is assigned, the person who opened the issue gets it.
  • Once it is overdue, the reminder repeats at most once a week, for up to four weeks after the due date.
  • One email a day at most. Everything due tomorrow and everything overdue is collected into one email, in two sections: Due tomorrow and Overdue. Each item links to the issue and shows its due date.
  • Which issues: open issues, not pull requests, in your organisations’ repositories. Closed issues, archived repositories and repositories in a personal namespace are not included.
  • Timing: the email goes out at 05:15 UTC (07:15 in Copenhagen in summer, 06:15 in winter). “Tomorrow” is the next calendar day in Copenhagen. The due date is the date Forgejo shows on the issue.
  • Access: you only get reminders about repositories you can still read when the email is sent. If you lose access to a repository after being assigned, its issues drop out of your reminders.
  • Language: the email is in the language you picked in Forgejo, in English, Danish, German, French, Dutch or Swedish. Other languages get English.
  • Who is skipped: bots, deactivated accounts and accounts without a verified email address.

To stop the reminders, turn off Issue due-date reminders for an organisation in notification settings, or use the one-click unsubscribe link at the bottom of any reminder, which turns them off for every organisation the reminder covered. Turning them back on is done in notification settings.

Data export

All issues and PRs are included in the full org data export bundle. See Data export.

Cross-references