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_runnerwith Docker, its default); - a runner label
ubuntu-latest(the default labels include it), or changeruns-onin the file to one of yours; - outbound HTTPS from the runner to
app.mopokehq.comand togitlab.boosoft.com.au:5050, where the public scanner image lives.
1. Add the token
Section titled “1. Add the token”- In MopokeHQ, make a CI token: organisation menu, CI tokens, kind CI pipeline (Tokens and keys).
- 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.
2. Add the workflow
Section titled “2. Add the workflow”Save MopokeHQ’s workflow file in the repository. On Gitea:
mkdir -p .gitea/workflowscurl -fsSL -o .gitea/workflows/mopoke.yml https://app.mopokehq.com/ci/gitea.ymlOn Forgejo, save the same file as .forgejo/workflows/mopoke.yml:
mkdir -p .forgejo/workflowscurl -fsSL -o .forgejo/workflows/mopoke.yml https://app.mopokehq.com/ci/gitea.ymlCommit 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.
Options
Section titled “Options”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. |
Pull requests and the merge gate
Section titled “Pull requests and the merge gate”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.
Report deployments
Section titled “Report deployments”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.
Fixing what it finds
Section titled “Fixing what it finds”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.