CLI reference

argus mr

The publication command. mr takes patches that already exist on disk and opens a merge request for each one. It is the back half of the pipeline, separated out.

Synopsis

terminal

export GITLAB_PRIVATE_TOKEN=glpat-your-token-here

argus mr \
  --patches patches/ \
  --gitlab-url https://gitlab.example.com \
  --project-id 4567

export GITLAB_PRIVATE_TOKEN=glpat-your-token-here

argus mr \
  --patches patches/ \
  --gitlab-url https://gitlab.example.com \
  --project-id 4567

What it does

mr reads the patches in the directory given by --patches (patches/ by default, the same place fix writes them) and publishes each as a GitLab merge request. Running fix and then mr is the two-step form of a full run, useful when you want to inspect or qualify the patches between planning and publication.

Connection and auth

Like run, mr needs to know where GitLab is and how to authenticate. Supply --gitlab-url and --project-id, and put your token in GITLAB_PRIVATE_TOKEN. Inside GitLab CI these flags default to the CI_* variables, so the command shortens to little more than argus mr. The full set of connection options is on the Global flags page.

Branches and labels

Each merge request is created on its own source branch, named to read like the fix: it leads with the vulnerability and affected artifact (argus/security/<cve>-<artifact>) rather than an internal strategy name, with cleanup-only MRs under argus/maintenance/. The argus prefix is set with --branch-prefix or ARGUS_BRANCH_PREFIX. Merge requests are labelled security,argus plus a severity label by default; change the defaults with --labels or append organisation-specific ones with ARGUS_EXTRA_LABELS. Breaking changes get an additional label set by --breaking-change-label. See Merge requests for the full lifecycle.