Create Pull Request (Forgejo)

Forgejo's peter-evans/create-pull-request. Take the changes in your workspace, commit them to a branch, push, and open or update a pull request, all through the Forgejo API. No github.com.

Part of the Fjord Actions bundle.

Usage

permissions:
  contents: write
  pull-requests: write

jobs:
  bump:
    runs-on: [self-hosted, Linux]
    steps:
      - uses: actions/checkout@v6

      - run: ./scripts/update-deps.sh    # makes whatever changes you want in the tree

      - uses: https://rasterhub.com/rasterstate/create-pull-request-action@v1
        with:
          branch: deps/weekly
          title: 'chore(deps): weekly bump'
          commit-message: 'chore(deps): weekly bump'
          body: Automated dependency update.
          labels: automated, deps
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}   # a Forgejo token on Forgejo

If there are no changes in the tree, the action is a no-op (pull-request-operation = none). Re-running with the same branch force-updates the branch and updates the existing PR rather than opening a duplicate. If the existing PR for the same head/base was closed, it is reopened and its title/body refreshed (pull-request-operation = reopened).

For a branch that branch protection forbids force-pushing (a protected automation branch, or one that must keep linear history), set push-strategy to merge or rebase. The action then folds the existing remote branch into the new commit and pushes without force, failing cleanly if it cannot fast-forward instead of overwriting. See Update strategy.

Inputs

Input	Default	Description
branch	create-pull-request/patch	Head branch to create/update.
base	repo default branch	Branch to merge into.
title	commit message	PR title.
body		PR body.
commit-message	Automated changes	Commit message for the staged changes.
add-paths	all (git add -A)	Paths to stage, one per line.
labels		Labels for a new PR, comma/newline separated (by name).
reviewers		Users to request review from on a new PR, comma/newline separated.
assignees		Users to assign to a new PR, comma/newline separated.
milestone		Milestone for a new PR, by title or numeric id.
project		Project to link a new PR to, by title or numeric id (needs the projects API).
draft	false	Open as a draft (WIP: title prefix on Forgejo).
push-strategy	force	How to update an existing branch: force, merge, rebase, or fail-if-diverged. See Update strategy.
author-name	GITHUB_ACTOR	Git author/committer name.
author-email		Git author/committer email.
path	.	Working directory of the repo.
token	GITHUB_TOKEN env	Forgejo token with repo write.
repository	GITHUB_REPOSITORY	Target repo owner/name.
api_url	derived	Forgejo API base.

Outputs

Output	Description
pull-request-number	PR number (empty when there were no changes).
pull-request-url	PR web URL.
pull-request-operation	created / updated / reopened / none.
pull-request-branch	Head branch that was pushed.
pull-request-head-sha	Commit SHA pushed to the head branch.

PR metadata

labels, reviewers, assignees, milestone, and project are applied to a newly created PR. Re-running on an existing PR updates the branch, title, and body but leaves the metadata alone, so a reviewer or milestone set by hand is not re-stamped on every run.

Each is best-effort and validated, so a bad value warns rather than failing the whole step:

• reviewers / assignees: comma/newline separated logins, matched against the repo's reviewable/assignable users. An unknown name warns and is skipped; the valid names are still applied.
• milestone: matched by title, or treated as a milestone id when it is all digits. An unknown milestone warns and is skipped.
• project: by title or numeric id. Linking needs a Forgejo build that exposes the projects API; on a build without it the input warns and is skipped rather than failing.

Update strategy

When the head branch already exists on the remote, push-strategy controls how it is updated:

• force (default): force-push, overwriting the remote branch. Best for throwaway automation branches; matches the original behavior.
• merge: fetch the remote branch and fold it into the new commit with a merge commit, then push without force. Use for a protected branch that forbids force-pushing.
• rebase: fetch the remote branch and replay the new commit onto it, then push without force. Use when the branch must keep linear history.
• fail-if-diverged (alias no-force): push without force and stop if the branch is not a fast-forward. Use when the branch is only ever appended to and a divergence should fail the run.

merge and rebase push without force, so a branch protection rule that blocks force updates is respected. A merge or rebase conflict, or a non-fast-forward push, fails the step cleanly and leaves the remote branch untouched rather than overwriting it.

Requirements

• Run after actions/checkout so there's a repo to work in.
• permissions: contents: write (push the branch) and pull-requests: write (open the PR).

See MIGRATION.md for differences from peter-evans/create-pull-request.

License

MIT, see LICENSE.