Skip to content

Set up Gitea and Forgejo

On Gitea and Forgejo, MopokeHQ runs as an Actions workflow in your repository, with the same scanner image and CLI as the GitLab setup. It runs on your own runners and only sends results out, so an instance behind a firewall works as is.

You need:

  • Actions turned on for the repository, and a runner that can run job containers (act_runner with Docker, its default);
  • a runner label ubuntu-latest (the default labels include it), or change runs-on in the file to one of yours;
  • outbound HTTPS from the runner to app.mopokehq.com and to gitlab.boosoft.com.au:5050, where the public scanner image lives.
  1. In MopokeHQ, make a CI token: organisation menu, CI tokens, kind CI pipeline (Tokens and keys).
  2. In Gitea or Forgejo, on the repository: Settings, Actions, Secrets, Add secret. Name MOPOKE_TOKEN, value the token.

To cover every repository at once, add it as an organisation secret instead.

Save MopokeHQ’s workflow file in the repository. On Gitea:

Terminal window
mkdir -p .gitea/workflows
curl -fsSL -o .gitea/workflows/mopoke.yml https://app.mopokehq.com/ci/gitea.yml

On Forgejo, save the same file as .forgejo/workflows/mopoke.yml:

Terminal window
mkdir -p .forgejo/workflows
curl -fsSL -o .forgejo/workflows/mopoke.yml https://app.mopokehq.com/ci/gitea.yml

Commit it and push to the default branch. The MopokeHQ workflow runs, and the repository appears in MopokeHQ. That first default-branch scan is the baseline: what it finds is existing work, listed and prioritised, but never counted against a pull request.

The workflow:

  • runs on pushes to the default branch, on tags and on pull requests, and by hand;
  • runs in the scanner image gitlab.boosoft.com.au:5050/mopokehq/scanner:1, which needs no login, and checks out with plain git, so the runner needs no Node.js;
  • checks dependencies, code, secrets, infrastructure files and licences (see Scanners), then uploads the results;
  • on pull requests, fetches the pull request’s own commits too, so a secret added and removed within it is still caught;
  • never fails unless you enforce the merge gate (below). A scanner or upload problem shows as a warning.

Set these as repository or organisation variables (Settings, Actions, Variables):

Variable Use
MOPOKE_SCANNERS Which scanners run: a list like sbom,secrets, or removals like -licence.
MOPOKE_GATE enforce: a pull request that fails the merge gate fails the workflow.
MOPOKE_SCANNER_IMAGE Your mirror of the scanner image, for runners that cannot reach the public one.

Each pull request is compared with the branch it targets, and the Scan step’s log shows the merge gate result: pass, warn or fail, with the reasons. Only what the pull request adds counts.

To block a pull request that fails the gate, set the project’s merge gate to Enforce in MopokeHQ (Settings, Projects) and set the variable MOPOKE_GATE to enforce. The workflow then fails on a failed gate, and nothing else. Make it a required check in the branch protection rules to stop merges.

A native Gitea and Forgejo integration (a pull request comment and a gate check) is coming. Until then, the log is where the gate shows.

MopokeHQ needs to know what is live: a problem in a deployed build is confirmed live, and a fix closes on its own only once MopokeHQ sees it deployed (see Priorities and deadlines). After a deploy succeeds, run mopoke deploy in the scanner image, or anywhere the CLI is installed:

mopoke-deploy:
needs: deploy
runs-on: ubuntu-latest
container:
image: gitlab.boosoft.com.au:5050/mopokehq/scanner:1
env:
MOPOKE_TOKEN: ${{ secrets.MOPOKE_TOKEN }}
steps:
- run: mopoke deploy --env production || echo "MopokeHQ: deploy not recorded"

It reads the repository and commit from the runner’s own variables and needs no checkout.

Each action on the Now screen names the version to upgrade to and every repository that needs it. Fix merge requests (mopoke act) are GitLab only for now, so make the change in your usual way; the next default-branch scan and deploy report close it.