ReARM CLI

This tool allows for command-line interactions with ReARM, website at https://rearmhq.com. ReARM is a Release-Level Supply Chain Evidence Platform. It allows to manage software and hardware releases with their Metadata, including SBOMs / xBOMs and other security artifacts. It supports BOMs in CycloneDX (primarily) and SPDX standards.

Community forum and support is available via Discord - use #rearm channel.

Container image URI: registry.relizahub.com/library/rearm-cli.

Download ReARM CLI

We're now using GitHub Releases for distribution. You can find the latest releases at https://github.com/relizaio/rearm-cli/releases.

Authentication

It is possible to set authentication data via:

explicit flags (-i for API Key ID, -k for API Key, -u for ReARM Uri)
login command
or following environment variables:

REARM_APIKEYID - for API Key ID
REARM_APIKEY - for API Key itself
REARM_URI - for ReARM Uri

Table of Contents - Use Cases

1. Use Case: Get Version Assignment From ReARM

This use case requests Version from ReARM for our component. Note that component schema must be preset on ReARM prior to using this API. API key must also be generated for the component from ReARM.

Sample command for semver version schema:

docker run --rm registry.relizahub.com/library/rearm-cli    \
    getversion    \
    -i component_or_organization_wide_rw_api_id    \
    -k component_or_organization_wide_rw_api_key    \
    -b main    \
    --pin 1.2.patch

Sample command with commit details for a git commit:

docker run --rm registry.relizahub.com/library/rearm-cli    \
    getversion    \
    -i component_or_organization_wide_rw_api_id    \
    -k component_or_organization_wide_rw_api_key    \
    -b main    \
    --vcstype git \
    --commit $CI_COMMIT_SHA \
    --commitmessage $CI_COMMIT_MESSAGE \
    --vcsuri $CI_PROJECT_URL \
    --date $(git log -1 --date=iso-strict --pretty='%ad')

Sample command to obtain only version info and skip creating the release:

docker run --rm registry.relizahub.com/library/rearm-cli    \
    getversion    \
    -i component_or_organization_wide_rw_api_id    \
    -k component_or_organization_wide_rw_api_key    \
    -b main    \
    --onlyversion

Sample command using VCS-based component resolution:

docker run --rm registry.relizahub.com/library/rearm-cli    \
    getversion    \
    -i organization_wide_rw_api_id    \
    -k organization_wide_rw_api_key    \
    --vcsuri github.com/myorg/myapp    \
    -b main

This approach identifies the component by VCS URI instead of component UUID, simplifying CI/CD integration. For monorepos with multiple components in one repository, add --repo-path to specify the subdirectory (e.g., --repo-path frontend).

Flags stand for:

getversion - command that denotes we are obtaining the next available release version for the branch. Note that if the call succeeds, the version assignment will be recorded and will not be given again by ReARM, even if it is not consumed. It will create the release with 'PENDING' lifecycle.
-i - flag for component api id (required).
-k - flag for component api key (required).
-b - flag to denote branch (required). If the branch is not recorded yet, ReARM will attempt to create it.
component - flag to denote component uuid (optional). Required if organization-wide read-write key is used, ignored if component specific api key is used.
--pin - flag to denote branch pin (optional for existing branches, required for new branches). If supplied for an existing branch and pin is different from current, it will override current pin.
--vcsuri - flag to denote vcs uri (optional). This flag is needed if we want to set a commit for the release. However, soon it will be needed only if the vcs uri is not yet set for the component.
--vcstype - flag to denote vcs type (optional). Supported values: git, svn, mercurial. As with vcsuri, this flag is needed if we want to set a commit for the release. However, soon it will be needed only if the vcs uri is not yet set for the component.
--commit - flag to denote vcs commit id or hash (optional). This is needed to provide source code entry metadata into the release.
--commitmessage - flag to denote vcs commit message (optional). Alongside commit flag this would be used to provide source code entry metadata into the release.
--commits - flag to provide base64-encoded list of commits in the format git log --date=iso-strict --pretty='%H|||%ad|||%s|||%an|||%ae' | base64 -w 0 (optional). If commit flag is not set, top commit will be used as commit bound to release. Mutually exclusive with --commitsfile.
--commitsfile - path to a file containing the same base64-encoded commits payload as --commits (optional). Useful in CI environments where the shell's maximum argument length would be exceeded by passing the full string on the command line. Mutually exclusive with --commits.
--date - flag to denote date time with timezone when commit was made, iso strict formatting with timezone is required, i.e. for git use git log --date=iso-strict (optional).
--vcstag - flag to denote vcs tag (optional). This is needed to include vcs tag into commit, if present.
--metadata - flag to set version metadata (optional). This may be semver metadata or custom version schema metadata.
--modifier - flag to set version modifier (optional). This may be semver modifier or custom version schema metadata.
--manual - flag to indicate a manual release (optional). Sets lifecycle as 'DRAFT', otherwise 'PENDING' lifecycle is set.
--onlyversion - boolean flag to skip creation of the release (optional). Default is false.
--rebuild - boolean flag to opt in to reusing an existing version assignment for this commit on this branch (optional). Default is false. Without this flag, getversion fails when a version was already minted for this (component, branch, commit) tuple — guards CI against two events on the same head (e.g. push and pull_request) racing into separate releases. With --rebuild, the existing version is returned, so an intentional re-issue of an artifact for the same commit stays idempotent. No effect when --commit is not supplied (manual mints, marketing-version requests).
--repo-path - Repository path for monorepo components (optional).
--action - Bump action name: bump | bumppatch | bumpminor | bumpmajor | bumpdate (optional).
--createcomponent - flag to create component if it doesn't exist (optional). Requires organization-wide read-write API key. When set, if the component identified by --vcsuri (and optionally --repo-path) doesn't exist, it will be automatically created.
--createcomponent-version-schema - version schema for the new component (optional). Only used with --createcomponent. Supported values: semver, calver_reliza, calver_ubuntu, calver_yy_mm, calver_yyyy_mm, calver_yy_0m, calver_yyyy_0m, custom based on options in Reliza Versioning (see here). Requires organization-wide read-write API key.
--createcomponent-branch-version-schema - feature branch version schema for the new component (optional). Only used with --createcomponent. Same supported values as --createcomponent-version-schema. Requires organization-wide read-write API key.
--createcomponent-name - display name for the new component (optional). Only used with --createcomponent. If not set, ReARM will derive the name from the VCS URI. Requires organization-wide read-write API key.
--vcs-display-name - Display name for VCS repository (optional, used when auto-creating VCS - if not set when auto-creating VCS would resolve to ReARM defaults).
--perspective - perspective UUID (optional). When supplied together with --createcomponent and the component does not yet exist, the auto-created component is assigned to this perspective. Requires a FREEFORM API key with WRITE permission on the perspective (or a broader scope that covers it) — organization-wide read-write keys are also accepted because they cover any perspective implicitly. Ignored when the component already exists.
--pr-identity - SCM-side identity of the PR / MR / change-list (optional, string). When set together with source code entry input (commit/sce details) and without --onlyversion, getversion also upserts a first-class PullRequest entity in ReARM keyed by (target VCS, identity) and advances its head to the SCE just persisted. Same flag set is also accepted on addrelease (see addrelease use case below); the upsert is idempotent on (targetVcs, identity) so running both is safe.
--pr-state - PR state (optional, required when --pr-identity is set). Supported values: OPEN, CLOSED, MERGED.
--pr-title - PR title (optional).
--pr-source-branch-name - source branch name (optional, the branch the PR is being merged from).
--pr-target-branch-name - target branch name (optional, the branch the PR is being merged into, e.g. main).
--pr-endpoint - URL of the PR in the upstream SCM (optional).

Sample command using a FREEFORM key scoped to a perspective to auto-create the component into that perspective:

docker run --rm registry.relizahub.com/library/rearm-cli    \
    getversion    \
    -i freeform_perspective_write_api_id    \
    -k freeform_perspective_write_api_key    \
    --vcsuri github.com/myorg/myapp    \
    --repo-path frontend    \
    -b main    \
    --createcomponent    \
    --perspective 4b272da8-2fea-4f13-a6a4-8e6e746c6e86

2. Use Case: Send Release Metadata to ReARM

This use case is commonly used in the CI workflow to stream Release metadata to ReARM. As in previous case, API key must be generated for the component on ReARM prior to sending release details.

Sample command to send release details:

docker run --rm registry.relizahub.com/library/rearm-cli    \
    addrelease    \
    -i component_or_organization_wide_rw_api_id    \
    -k component_or_organization_wide_rw_api_key    \
    -b master    \
    -v 20.02.3    \
    --vcsuri github.com/registry.relizahub.com/library/rearm-cli    \
    --vcstype git    \
    --commit 7bfc5ce7b0da277d139f7993f90761223fa54442    \
    --vcstag 20.02.3    \
    --odelid registry.relizahub.com/library/rearm-cli    \
    --odelbuildid 1    \
    --odelcimeta Github Actions    \
    --odeltype CONTAINER    \
    --odeldigests sha256:4e8b31b19ef16731a6f82410f9fb929da692aa97b71faeb1596c55fbf663dcdd

Sample command with all three artifact types (Source Code Entry, Release, and Deliverable artifacts):

docker run --rm registry.relizahub.com/library/rearm-cli    \
    addrelease    \
    -i component_or_organization_wide_rw_api_id    \
    -k component_or_organization_wide_rw_api_key    \
    -b main    \
    -v 1.0.0    \
    --vcsuri github.com/myorg/myapp    \
    --vcstype git    \
    --commit abc123def456    \
    --vcstag v1.0.0    \
    --date 2025-11-20T15:30:00Z    \
    --scearts '[{"displayIdentifier":"build-log","type":"BUILD_META","storedIn":"REARM","filePath":"./build.log"}]'    \
    --releasearts '[{"displayIdentifier":"release-notes-v1.0.0","type":"RELEASE_NOTES","storedIn":"EXTERNALLY","downloadLinks":[{"uri":"https://docs.example.com/releases/v1.0.0","content":"Release Notes"}]},{"displayIdentifier":"security-report","type":"USER_DOCUMENT","storedIn":"REARM","filePath":"./security-report.pdf"}]'    \
    --odelid myapp-docker-image    \
    --odeltype CONTAINER    \
    --odeldigests sha256:abc123def456    \
    --odelartsjson '[{"displayIdentifier":"myapp-sbom","type":"BOM","bomFormat":"CYCLONEDX","storedIn":"REARM","inventoryTypes":["SOFTWARE"],"filePath":"./sbom.json"},{"displayIdentifier":"myapp-attestation","type":"ATTESTATION","storedIn":"REARM","filePath":"./attestation.json"}]'

Understanding Artifact Types:

The addrelease command supports three types of artifacts, each serving a different purpose:

Source Code Entry Artifacts (--scearts): Artifacts attached to the commit/source code entry
- Examples: Source Code SBOM
- Use when: The artifact is specific to the source code at that commit
Release Artifacts (--releasearts): Artifacts attached directly to the release
- Examples: Release notes, security reports, user documentation, certifications
- Use when: The artifact describes or documents the release as a whole
Deliverable Artifacts (--odelartsjson): Artifacts attached to specific deliverables
- Examples: SBOMs, attestations, signatures, VEX documents
- Use when: The artifact is specific to a deliverable (container, binary, package)
- Note: Must have one --odelartsjson entry per --odelid deliverable

Using Tags on Artifacts:

Tags can be added to artifacts in --releasearts, --scearts, and --odelartsjson using the tags field. Tags are key-value pairs useful for categorization, filtering, and metadata.

Example with tags on release artifacts:

--releasearts '[{"displayIdentifier":"security-report","type":"USER_DOCUMENT","storedIn":"REARM","filePath":"./security-report.pdf","tags":[{"key":"category","value":"security"},{"key":"reviewed","value":"true"}]}]'

Example with tags on SCE artifacts:

--scearts '[{"displayIdentifier":"source-sbom","type":"BOM","bomFormat":"CYCLONEDX","storedIn":"REARM","filePath":"./source-sbom.json","tags":[{"key":"generator","value":"cdxgen"},{"key":"scope","value":"source"}]}]'

Example with tags on deliverable artifacts:

--odelartsjson '[{"displayIdentifier":"container-sbom","type":"BOM","bomFormat":"CYCLONEDX","storedIn":"REARM","inventoryTypes":["SOFTWARE"],"filePath":"./sbom.json","tags":[{"key":"format","value":"cyclonedx"},{"key":"version","value":"1.5"}]}]'

Example with nested artifacts (artifacts within artifacts) with tags:

--odelartsjson '[{"displayIdentifier":"main-sbom","type":"BOM","bomFormat":"CYCLONEDX","storedIn":"REARM","filePath":"./main-sbom.json","tags":[{"key":"primary","value":"true"}],"artifacts":[{"displayIdentifier":"nested-vex","type":"VEX","storedIn":"REARM","filePath":"./vex.json","tags":[{"key":"type","value":"openvex"}]}]}]'

Artifact Coverage Type Tags:

To tag artifacts with coverage types (e.g., DEV, TEST, BUILD_TIME), include COVERAGE_TYPE tags in the artifact JSON tags field. These tags indicate the type of dependencies included in the artifact and can be used to filter artifacts during BOM export.

Supported coverage type values: DEV, TEST, BUILD_TIME.

Example with a single coverage type:

--odelartsjson '[{"displayIdentifier":"dev-sbom","type":"BOM","bomFormat":"CYCLONEDX","storedIn":"REARM","filePath":"./sbom.json","tags":[{"key":"COVERAGE_TYPE","value":"DEV"}]}]'

Example with multiple coverage types on the same artifact:

--releasearts '[{"displayIdentifier":"build-sbom","type":"BOM","bomFormat":"CYCLONEDX","storedIn":"REARM","filePath":"./sbom.json","tags":[{"key":"COVERAGE_TYPE","value":"DEV"},{"key":"COVERAGE_TYPE","value":"BUILD_TIME"}]}]'

Sample command using VCS-based component resolution:

docker run --rm registry.relizahub.com/library/rearm-cli    \
    addrelease    \
    -i organization_wide_rw_api_id    \
    -k organization_wide_rw_api_key    \
    --vcsuri github.com/myorg/myapp    \
    -b main    \
    -v 1.0.0    \
    --commit abc123def456

This approach identifies the component by VCS URI instead of component UUID, eliminating the need to track UUIDs in CI/CD workflows. For monorepos with multiple components in one repository, add --repo-path to specify the subdirectory (e.g., --repo-path frontend).

Flags stand for:

addrelease - command that denotes we are sending Release Metadata of a Component to ReARM.
-i - flag for component api id or organization-wide read-write api id (required).
-k - flag for component api key or organization-wide read-write api key (required).
-b - flag to denote branch (required). If branch is not recorded yet, ReARM will attempt to create it.
-v - version (required). Note that ReARM will reject the call if a release with this exact version is already present for this component.
endpoint - flag to denote test endpoint URI (optional). This would be useful for systems where every release gets test URI.
component - flag to denote component uuid (optional). Required if organization-wide read-write key is used, ignored if component specific api key is used.
vcsuri - flag to denote vcs uri (optional). Currently this flag is needed if we want to set a commit for the release. However, soon it will be needed only if the vcs uri is not yet set for the component.
commit - flag to denote vcs commit id or hash (optional). This is needed to provide source code entry metadata into the release.
commitmessage - flag to denote vcs commit subject (optional). Alongside commit flag this would be used to provide source code entry metadata into the release.
commits - flag to provide base64-encoded list of commits in the format git log --date=iso-strict --pretty='%H|||%ad|||%s|||%an|||%ae' | base64 -w 0 (optional). If commit flag is not set, top commit will be used as commit bound to release. Mutually exclusive with --commitsfile.
commitsfile - path to a file containing the same base64-encoded commits payload as --commits (optional). Useful in CI environments where the shell's maximum argument length would be exceeded by passing the full string on the command line. Mutually exclusive with --commits.
scearts - flag to denote metadata Artifacts set on Source Code Entry - or commit (optional). Expects JSON Array representation, with Keys for each object: type, bomFormat, filePath. Sample entry:

[{"bomFormat": "CYCLONEDX","type": "BOM","filePath": "./fs.cdx.bom.json"}]

releasearts - flag to denote metadata Artifacts attached directly to the release (optional). Expects JSON Array representation, with Keys for each object: displayIdentifier, type, storedIn, filePath (or downloadLinks for external storage). Sample entry for internal storage:

[{"displayIdentifier": "release-notes-v1.0.0","type": "RELEASE_NOTES","storedIn": "REARM","filePath": "./release-notes.md"}]

Sample entry for external storage:

[{"displayIdentifier": "release-notes-v1.0.0","type": "RELEASE_NOTES","storedIn": "EXTERNALLY","downloadLinks": [{"uri": "https://docs.example.com/releases/v1.0.0","content": "Release Notes"}]}]

date - flag to denote date time with timezone when commit was made, iso strict formatting with timezone is required, i.e. for git use git log --date=iso-strict (optional, required if commit is present).
vcstag - flag to denote vcs tag (optional). This is needed to include vcs tag into commit, if present.
lifecycle - flag to denote release lifecycle (optional). Set to 'REJECTED' for failed releases, otherwise 'DRAFT' is used, may be also set to 'ASSEMBLED'.
odelid - flag to denote output deliverable identifier (optional). This is required to add output deliverable metadata into release.
odelbuildid - flag to denote output deliverable build id (optional). This flag is optional and may be used to indicate build system id of the release (i.e., this could be circleci build number).
odelbuilduri - flag to denote output deliverable build uri (optional). This flag is optional and is used to denote the uri for where the build takes place.
odelcimeta - flag to denote output deliverable CI metadata (optional). This flag is optional and like odelbuildid may be used to indicate build system metadata in free form.
odeltype - flag to denote output deliverable type (optional). Types are based on CycloneDX 1.6 spec - refer to lines 836-850 in the spec. Supported values (case-insensitive): Application, Framework, Library, Container, Platform, Operatine-system, Device, Device-driver, Firmware, File, Machine-learning-model, Data, Cryptographic-asset.
--odelidentifiers - Deliverable Identifiers (i.e. PURL) IdentifierType-Value Pairs (multiple allowed, separate several IdentifierType-Value pairs for one Deliverable with commas, and seprate IdentifierType-Value in a pair with colon, e.g. --odelidentifiers "PURL:somepurl,TEI:sometei")
datestart - flag to denote output deliverable build start date and time, must conform to ISO strict date (in bash, use date -Iseconds, if used there must be one datestart flag entry per deliverable, optional).
dateend - flag to denote output deliverable build end date and time, must conform to ISO strict date (in bash, use date -Iseconds, if used there must be one datestart flag entry per deliverable, optional).
odelpublisher - flag to denote output deliverable publisher (if used there must be one publisher flag entry per deliverable, optional).
odeldigests - flag to denote output deliverable digests (optional). By convention, digests must be prefixed with type followed by colon and then actual digest hash, i.e. sha256:4e8b31b19ef16731a6f82410f9fb929da692aa97b71faeb1596c55fbf663dcdd - here type is sha256 and digest is 4e8b31b19ef16731a6f82410f9fb929da692aa97b71faeb1596c55fbf663dcdd. Multiple digests are supported and must be comma separated. I.e.:

--odeldigests sha256:4e8b31b19ef16731a6f82410f9fb929da692aa97b71faeb1596c55fbf663dcdd,sha1:fe4165996a41501715ea0662b6a906b55e34a2a1

odelartsjson - flag to denote metadata Artifacts set on Output Deliverable(optional). Format is similar to scearts - expects JSON Array representation, with Keys for each object: type, bomFormat, filePath
--repo-path - Repository path for monorepo components (optional).
--releasearts - Release Artifacts json array (optional).
--odelgroup - Deliverable group (multiple allowed, optional).
--odelpackage - Deliverable package type (multiple allowed, optional).
--osarr - Deliverable supported OS array (multiple allowed, use comma seprated values for each deliverable, optional).
--cpuarr - Deliverable supported CPU array (multiple allowed, use comma seprated values for each deliverable, optional).
--odelversion - Deliverable version, if different from release (multiple allowed, optional).
--tagsarr - Deliverable Tag Key-Value Pairs (multiple allowed, separate several tag key-value pairs for one Deliverable with commas, and seprate key-value in a pair with colon, optional).
--stripbom - flag to toggle stripping of bom metadata for hash comparison (optional). Default is true. Supported values: true|false.
--createcomponent - flag to create component if it doesn't exist (optional). Requires organization-wide read-write API key. When set, if the component identified by --vcsuri (and optionally --repo-path) doesn't exist, it will be automatically created.
--createcomponent-version-schema - version schema for the new component (optional). Only used with --createcomponent. Supported values: semver, calver_reliza, calver_ubuntu, calver_yy_mm, calver_yyyy_mm, calver_yy_0m, calver_yyyy_0m, custom based on options in Reliza Versioning (see here). Requires organization-wide read-write API key.
--createcomponent-branch-version-schema - feature branch version schema for the new component (optional). Only used with --createcomponent. Same supported values as --createcomponent-version-schema. Requires organization-wide read-write API key.
--createcomponent-name - display name for the new component (optional). Only used with --createcomponent. If not set, ReARM will derive the name from the VCS URI. Requires organization-wide read-write API key.
--perspective - perspective UUID (optional). When supplied together with --createcomponent and the component does not yet exist, the auto-created component is assigned to this perspective. Requires a FREEFORM API key with WRITE permission on the perspective (or a broader scope that covers it). Ignored when the component already exists. FREEFORM keys may also be used without --perspective to reach existing components whose scope (organization, perspective, or component) is covered by the key's permissions.
--vcs-display-name - Display name for VCS repository (optional, used when auto-creating VCS - if not set when auto-creating VCS would resolve to ReARM defaults).
vcstype - flag to denote vcs type (optional). Supported values: git, svn, mercurial. This flag is needed if we want to set a commit for the release only if the vcs uri is not yet set for the component and we're creating a new component with new vcs uri.
--rebuild - flag to allow rebuilding release on repeated CI reruns (optional). Default is false. When set to true, if a release with the same version already exists, it will be rebuilt instead of rejected.
--pr-identity - SCM-side identity of the PR / MR / change-list (optional, string). GitHub PR number ("42"), GitLab MR iid, or Gerrit change-id all work. When set, addrelease also upserts a first-class PullRequest entity in ReARM keyed by (target VCS, identity) and advances its head to the just-created release's source code entry. -b should be the PR head branch (e.g. github.head_ref), not the synthetic merge ref.
--pr-state - PR state (optional, required when --pr-identity is set). Supported values: OPEN, CLOSED, MERGED.
--pr-title - PR title (optional).
--pr-source-branch-name - source branch name (optional, the branch the PR is being merged from).
--pr-target-branch-name - target branch name (optional, the branch the PR is being merged into, e.g. main).
--pr-endpoint - URL of the PR in the upstream SCM (optional).

Note that multiple deliverables per release are supported. In which case deliverable specific flags (odelid, odelbuildid, odelbuilduri, odelcimeta, odeltype, odeldigests, odelartsjson must be repeated for each deliverable).

For sample of how to use workflow in CI, refer to the ReARM Add Release GitHub Action here.

3a. Use Case: Check If Deliverable Hash Already Present In Some Release

This is particularly useful for monorepos to see if there was a change in sub-component or not. We supply a deliverable hash to ReARM - and if it's present already, we get release details as a CycloneDX 1.6 BOM string; if not - we get an empty json response {}. Search space is scoped to a single component which is defined by API Id and API Key.

Sample command:

docker run --rm registry.relizahub.com/library/rearm-cli    \
    checkhash    \
    -i component_or_org_wide_api_id    \
    -k component_or_org_wide_api_key    \
    --hash sha256:hash

Flags stand for:

checkhash - command that denotes we are checking artifact hash.
-i - flag for component api id (required).
-k - flag for component api key (required).
--hash - flag to denote actual hash (required). By convention, hash must include hashing algorithm as its first part, i.e. sha256: or sha512:
--component - flag to denote UUID of specific Component, UUID must be obtained from ReARM (required if org-wide or user api key is used).

3b. Use Case: Get Release By Version

This command retrieves release data for a specific version of a component. It returns the release details as a CycloneDX 1.6 BOM string.

Sample command:

docker run --rm registry.relizahub.com/library/rearm-cli    \
    releasebyversion    \
    -i component_or_org_wide_api_id    \
    -k component_or_org_wide_api_key    \
    --component component_uuid    \
    --version 1.0.0

Flags stand for:

releasebyversion - command that denotes we are retrieving release by version.
-i - flag for api id (required).
-k - flag for api key (required).
--component - flag to denote UUID of specific Component, UUID must be obtained from ReARM (required).
--version - flag to denote the version of the release to retrieve (required).

4. Use Case: Request Latest Release Per Component Or Product

This use case is when ReARM is queried either by CI or CD environment or by integration instance to check latest release version available per specific Component or Product.

By default, the command returns the latest release as a JSON object. Use the --cdx flag to return the release as a CycloneDX 1.6 BOM string instead.

Sample command:

docker run --rm registry.relizahub.com/library/rearm-cli    \
    getlatestrelease    \
    -i api_id    \
    -k api_key    \
    --component b4534a29-3309-4074-8a3a-34c92e1a168b    \
    --branch main

Flags stand for:

getlatestrelease - command that denotes we are requesting latest release data for Component or Product from ReARM
-i - flag for api id which can be either api id for this component or organization-wide read API (required).
-k - flag for api key which can be either api key for this component or organization-wide read API (required).
--component - flag to denote UUID of specific Component or Product, UUID must be obtained from ReARM (optional if component API key is used, either this or combination of vcsuri and repo-path must be set).
vcsuri - flag to denote uri of vcs repository for the component (used if component API key is not used and explicit component UUID is not provided).
--repo-path - Repository path for monorepo components (optional, used in combination with vcsuri for component resolution).
--product - flag to denote UUID of Product which packages Component or Product for which we inquiry about its version via --component flag, UUID must be obtained from ReARM (optional).
--branch - flag to denote required branch of chosen Component or Product (required).
--lifecycle - Lifecycle of the last known release to return, default is 'ASSEMBLED' (optional, can be - [CANCELLED, REJECTED, PENDING, DRAFT, ASSEMBLED, GENERAL_AVAILABILITY, END_OF_SUPPORT]). Will include all higher level lifecycles, i.e. if set to CANCELLED, will return releases in any lifecycle.
--operator - Match operator for a list of approvals, 'AND' or 'OR', default is 'AND' (optional).
--approvalentry - Approval entry names or IDs (optional, multiple allowed).
--approvalstate - Approval states corresponding to approval entries, can be 'APPROVED', 'DISAPPROVED' or 'UNSET' (optional, multiple allowed, required if approval entries are present).
--env - Environment to obtain approvals details from (optional).
--instance - Instance ID for which to check release (optional).
--namespace - Namespace within instance for which to check release, only matters if instance is supplied (optional).
--tagkey - Tag key to use for picking artifact (optional).
--tagval - Tag value to use for picking artifact (optional).
--uptoversion - Upper bound version to filter releases (optional). Returns latest release up to this version.
--cdx - Output release in CycloneDX 1.6 format (optional). When set, returns a CycloneDX 1.6 BOM string instead of the default JSON object.

5. Use Case: Persist ReARM Credentials in a Config File

This use case is for the case when we want to persist ReARM API Credentials and URL in a config file.

The login command saves API ID, API KEY and URI as specified by flags in a config file .rearm.env in the home directory for the executing user.

Sample Command:

docker run --rm \
    -v ~:/home/apprunner \
    registry.relizahub.com/library/rearm-cli \
    login \
    -i api_id \
    -k api_key \
    -u rearm_server_uri

Flags stand for:

-i - flag for api id.
-k - flag for api key.
-u - flag for rearm hub uri.

6. Use Case: Create New Component in ReARM

This use case creates a new component for our organization. API key must be generated prior to using.

Sample command to create component:

docker run --rm registry.relizahub.com/library/rearm-cli    \
    createcomponent    \
    -i org_api_id    \
    -k org_api_key    \
    --name componentname    \
    --type component    \
    --versionschema semver    \
    --featurebranchversioning Branch.Micro    \
    --vcsuri github.com/registry.relizahub.com/library/rearm-cli

Sample command for monorepo component:

docker run --rm registry.relizahub.com/library/rearm-cli    \
    createcomponent    \
    -i org_api_id    \
    -k org_api_key    \
    --name myapp-frontend    \
    --type component    \
    --versionschema semver    \
    --vcsuri github.com/myorg/myrepo    \
    --repo-path frontend

⚠️ Important: Version Schema Requirement

The --versionschema flag is critical for components created via API. Without it:

getversion command will fail with "missing version schema configuration" error
Version generation will not work
Component will need manual update via UI

Always include: --versionschema semver when creating components.

Flags stand for:

createcomponent - command that denotes we are creating a new component for our organization. Note that a vcs repository must either already exist or be created during this call.
-i - flag for org api id (required).
-k - flag for org api key (required).
name - flag to denote component name (required).
type - flag to denote component type (required). Supported values: component, product.
defaultbranch - flag to denote default branch name (optional, if not set "main" will be used). Available names are either main or master.
versionschema - flag to denote version schema (optional, if not set "semver" will be used). Available version schemas.
featurebranchversioning - flag to denote feature branch version schema (optional, if not set "Branch.Micro will be used).
vcsuuid - flag to denote uuid of vcs repository for the component (for existing repositories, either this flag or vcsuri are required).
vcsuri - flag to denote uri of vcs repository for the component, if existing repository with uri does not exist and vcsname and vcstype are not set, ReARM will attempt to autoparse github, gitlab, and bitbucket uri's.
vcsname - flag to denote name of vcs repository to create for component (required if ReARM cannot parse uri).
vcstype - flag to denote type of vcs to create for component. Supported values: git, svn, mercurial (required if ReARM cannot parse uri).
includeapi - boolean flag to return component api key and id of newly created component (optional). Default is false.
--repo-path - Repository path for monorepo components (optional).
--perspective - perspective UUID (optional). When supplied, the component is atomically created and assigned to the given perspective via the createComponentInPerspectiveProgrammatic mutation. Requires a FREEFORM API key with WRITE permission on the perspective (or a broader scope that covers it) — organization-wide keys are not sufficient for this path.

Sample command to create a component directly under a perspective:

docker run --rm registry.relizahub.com/library/rearm-cli    \
    createcomponent    \
    -i freeform_api_id    \
    -k freeform_api_key    \
    --name myapp    \
    --type component    \
    --versionschema semver    \
    --vcsuri github.com/myorg/myapp    \
    --perspective 4b272da8-2fea-4f13-a6a4-8e6e746c6e86

7. Use Case: Synchronize Live Git Branches with ReARM

Sends a list of Live Git branches to ReARM. Non-live branches present on ReARM will be archived.

Sample command using component UUID:

docker run --rm registry.relizahub.com/library/rearm-cli    \
    syncbranches \
    -i api_id \ 
    -k api_key    \
    --component component_uuid    \
    --livebranches $(git branch -r --format="%(refname)" | base64 -w 0)

Sample command using VCS-based component resolution:

docker run --rm registry.relizahub.com/library/rearm-cli    \
    syncbranches \
    -i organization_wide_rw_api_id    \
    -k organization_wide_rw_api_key    \
    --vcsuri github.com/myorg/myrepo    \
    --repo-path frontend    \
    --livebranches $(git branch -r --format="%(refname)" | base64 -w 0)

Flags stand for:

--component - flag to specify component uuid, which can be obtained from the component settings on ReARM UI (either this flag, vcsuri, or component's API key must be used).
--vcsuri - URI of VCS repository for VCS-based component resolution (optional, alternative to component UUID).
--repo-path - Repository path for monorepo components (optional, use with vcsuri when multiple components share one repository).
--livebranches - base64'd list of git branches, for local branches use git branch --format=\"%(refname)\" | base64 -w 0 to obtain, for remote branches use git branch -r --format=\"%(refname)\" | base64 -w 0. Choose between local and remote branches based on your CI context. Mutually exclusive with --livebranchesfile.
--livebranchesfile - path to a file containing the same base64-encoded live branches payload as --livebranches. Useful for repositories with many branches where the shell's maximum argument length would be exceeded. Mutually exclusive with --livebranches. Example: git branch -r --format="%(refname)" | base64 -w 0 > branches.b64 then --livebranchesfile branches.b64.

8. Use Case: Add Outbound Deliverables to Release

This use case adds outbound deliverables to a ReARM Release. Release must be in Pending or Draft lifecycle.

Sample command:

docker run --rm registry.relizahub.com/library/rearm-cli    \
    addodeliverable \
    -i api_id \ 
    -k api_key    \
    --odelid registry.relizahub.com/library/rearm-cli    \
    --odelbuildid 1    \
    --odelcimeta Github Actions    \
    --odeltype CONTAINER    \
    --odeldigests sha256:4e8b31b19ef16731a6f82410f9fb929da692aa97b71faeb1596c55fbf663dcdd
    --releaseid 22a98c21-ab90-4a17-94f5-2dd81be5647b

Flags stand for:

--component - Component UUID for this release, required if organization wide API Key is used
--cpuarr - Array of CPU architectures supported by this Deliverable (optional, multiple allowed)
--dateend - Deliverable Build End date and time (optional, multiple allowed)
--datestart - Deliverable Build Start date and time (optional, multiple allowed)
--odelidentifiers - Deliverable Identifiers (i.e. PURL) IdentifierType-Value Pairs (multiple allowed, separate several IdentifierType-Value pairs for one Deliverable with commas, and seprate IdentifierType-Value in a pair with colon, e.g. --odelidentifiers "PURL:somepurl,TEI:sometei")
--odelartsjson -Deliverable Artifacts json array (optional, multiple allowed, use a json array for each deliverable, similar to add release use case)
--odelbuildid - Deliverable Build ID (optional, multiple allowed)
--odelbuilduri - Deliverable Build URI (multiple allowed)
--odelcimeta - Deliverable CI Meta (multiple allowed)
--odeldigests - Deliverable Digests (multiple allowed, separate several digests for one Deliverable with commas)
--odelid - Deliverable Primary Identifier (multiple allowed)
--odelpackage - Deliverable package type (i.e. Maven) (multiple allowed)
--odelpublisher - Deliverable publisher (multiple allowed)
--odelgroup - Deliverable group (multiple allowed)
--odelversion - Deliverable version, if different from release (multiple allowed)
--osarr - Deliverable supported OS array (multiple allowed, use comma seprated values for each deliverable)
--releaseid - UUID of release to add deliverable to (either releaseid or component, branch, and version must be set)
--tagsarr - Deliverable Tag Key-Value Pairs (multiple allowed, separate several tag key-value pairs for one Deliverable with commas, and seprate key-value in a pair with colon)
--version - Release version (either releaseid or component, branch, and version must be set)
--branch - Release branch (either releaseid or component, branch, and version must be set)
--stripbom - flag to toggle stripping of bom metadata for hash comparison (optional - can). Default is true. Supported values: true|false.

9. Use Case: xBOM Utilities

See bomutils documentation

10. Use Case: Finalize Release After CI Completion

The releasefinalizer command is used to run a release finalizer, which can be executed after submitting a release or after adding a new deliverable to a release. This command signals the completion of the CI process for a release in ReARM, ensuring all post-release or post-deliverable actions are triggered.

Typical workflow:

Submit a release or add a new deliverable to a release Run the release finalizer to complete the CI process

Sample command (Docker):

docker run --rm registry.relizahub.com/library/rearm-cli \
    releasefinalizer \
    -i <component_or_org_wide_api_id> \
    -k <component_or_org_wide_api_key> \
    --releaseid <release_uuid>

Flags stand for :

--releaseid - UUID of the release to finalize (required)

This command can be integrated into CI/CD workflows to signal the end of the release process, ensuring that all finalization hooks and actions are called in ReARM.

11. Use Case: Transparency Exchange API (TEA) Commands

Base Command: tea See tea documentation

12. Use Case: Oolong TEA Server Content Management Commands

Base Command: oolong See oolong documentation

13. Use Case: VCS-based Component Resolution

ReARM supports identifying components by VCS repository URI in addition to component UUID:

Traditional (UUID-based):

getversion --component "4b272da8-2fea-4f13-a6a4-8e6e746c6e86" -b "main"

VCS-based (Recommended for CI/CD):

getversion --vcsuri "github.com/myorg/myapp" -b "main"

Benefits: Eliminates UUID management, uses repository context already available in CI/CD pipelines.

For Monorepos: Add --repo-path when multiple components share one repository:

getversion --vcsuri "github.com/myorg/myrepo" --repo-path "frontend" -b "main"

13.1: Creating Components

Single Repository:

createcomponent --name "myapp" --type "component" \
  --vcsuri "github.com/myorg/myapp" --versionschema "semver"

Monorepo (add --repo-path):

createcomponent --name "myapp-frontend" --type "component" \
  --vcsuri "github.com/myorg/myrepo" --repo-path "frontend" --versionschema "semver"

Key Flags:

--vcsuri - Repository URI for VCS-based resolution
--versionschema "semver" - Required for version generation
--repo-path - Optional, only for monorepos

13.2: Getting Versions

Single Repository:

getversion --vcsuri "github.com/myorg/myapp" -b "main"

Monorepo:

getversion --vcsuri "github.com/myorg/myrepo" --repo-path "frontend" -b "main"

13.3: Adding Releases

Single Repository:

addrelease --vcsuri "github.com/myorg/myapp" -b "main" -v "1.0.0"

Monorepo:

addrelease --vcsuri "github.com/myorg/myrepo" --repo-path "frontend" -b "main" -v "1.0.0"

13.4: Monorepo Support

For repositories with multiple components, use --repo-path to specify the subdirectory:

--vcsuri "github.com/myorg/myrepo" --repo-path "frontend"
--vcsuri "github.com/myorg/myrepo" --repo-path "backend"
--vcsuri "github.com/myorg/myrepo" --repo-path "services/auth"

14. Use Case: Add Artifacts to Existing Release

This use case adds artifacts to an existing release, deliverable, or source code entry (SCE) after the release has been created. This is useful when artifacts become available after the initial release creation, or when you need to add additional SBOMs, attestations, or other artifacts to existing entities.

Key Difference from addrelease:

addrelease creates a new release with artifacts
addartifact adds artifacts to an existing release, deliverable, or SCE

Simple Mode: Add Artifacts to Release

docker run --rm registry.relizahub.com/library/rearm-cli    \
    addartifact    \
    -i component_or_organization_wide_rw_api_id    \
    -k component_or_organization_wide_rw_api_key    \
    --component c6c3223f-7ad0-4d99-a69e-5afa151c71ca    \
    --version 1.0.5    \
    --artifacts '[{
      "filePath": "./release-sbom.json",
      "type": "BOM",
      "bomFormat": "CYCLONEDX",
      "storedIn": "REARM",
      "inventoryTypes": ["SOFTWARE"],
      "displayIdentifier": "release-sbom"
    }]'

Advanced Mode: Add Multiple Artifact Types

Add artifacts to release, deliverable, and SCE in a single command:

docker run --rm registry.relizahub.com/library/rearm-cli    \
    addartifact    \
    -i component_or_organization_wide_rw_api_id    \
    -k component_or_organization_wide_rw_api_key    \
    --component c6c3223f-7ad0-4d99-a69e-5afa151c71ca    \
    --version 1.0.5    \
    --releasearts '[{
      "filePath": "./release-sbom.json",
      "type": "BOM",
      "bomFormat": "CYCLONEDX",
      "storedIn": "REARM",
      "inventoryTypes": ["SOFTWARE"],
      "displayIdentifier": "release-sbom"
    }]'    \
    --deliverablearts '[{
      "deliverable": "035ad637-190b-40ba-a0ac-d7779ccc2c55",
      "artifacts": [{
        "filePath": "./container-sbom.json",
        "type": "BOM",
        "bomFormat": "CYCLONEDX",
        "storedIn": "REARM",
        "inventoryTypes": ["SOFTWARE"],
        "displayIdentifier": "container-sbom"
      }]
    }]'    \
    --scearts '[{
      "sce": "892baa07-2492-4231-b9cc-06e4b5487342",
      "artifacts": [{
        "filePath": "./source-sbom.json",
        "type": "BOM",
        "bomFormat": "CYCLONEDX",
        "storedIn": "REARM",
        "inventoryTypes": ["SOFTWARE"],
        "displayIdentifier": "source-sbom"
      }]
    }]'

Add Artifacts to Deliverable Only

docker run --rm registry.relizahub.com/library/rearm-cli    \
    addartifact    \
    -i component_or_organization_wide_rw_api_id    \
    -k component_or_organization_wide_rw_api_key    \
    --component c6c3223f-7ad0-4d99-a69e-5afa151c71ca    \
    --version 1.0.5    \
    --deliverablearts '[{
      "deliverable": "035ad637-190b-40ba-a0ac-d7779ccc2c55",
      "artifacts": [{
        "filePath": "./attestation.json",
        "type": "ATTESTATION",
        "storedIn": "REARM",
        "displayIdentifier": "build-attestation"
      }]
    }]'

Add Artifacts to Source Code Entry Only

docker run --rm registry.relizahub.com/library/rearm-cli    \
    addartifact    \
    -i component_or_organization_wide_rw_api_id    \
    -k component_or_organization_wide_rw_api_key    \
    --component c6c3223f-7ad0-4d99-a69e-5afa151c71ca    \
    --version 1.0.5    \
    --scearts '[{
      "sce": "892baa07-2492-4231-b9cc-06e4b5487342",
      "artifacts": [{
        "filePath": "./source-analysis.json",
        "type": "USER_DOCUMENT",
        "storedIn": "REARM",
        "displayIdentifier": "static-analysis-report"
      }]
    }]'

Flags:

addartifact - command that denotes we are adding artifacts to an existing release, deliverable, or SCE
-i - flag for component api id or organization-wide read-write api id (required)
-k - flag for component api key or organization-wide read-write api key (required)
--component - flag to denote component uuid (optional). Required if organization-wide read-write key is used, ignored if component specific api key is used
--version - release version to add artifacts to (either version+component or release uuid must be provided)
--release - release UUID to add artifacts to (alternative to version+component)
--artifacts - artifacts JSON array for simple mode (optional). Defaults to release artifacts. Mutually exclusive with specific artifact type flags
--releasearts - release artifacts JSON array (optional). Artifacts attached directly to the release
--deliverablearts - deliverable artifacts JSON array (optional). Each entry must specify deliverable UUID and artifacts. Format:

[{
  "deliverable": "uuid-of-deliverable",
  "artifacts": [{ artifact object }]
}]

--scearts - source code entry artifacts JSON array (optional). Each entry must specify SCE UUID and artifacts. Format:

[{
  "sce": "uuid-of-sce",
  "artifacts": [{ artifact object }]
}]

Artifact Object Format:

All artifact objects follow the same format as in addrelease:

{
  "filePath": "./path/to/file",
  "type": "BOM",
  "bomFormat": "CYCLONEDX",
  "storedIn": "REARM",
  "inventoryTypes": ["SOFTWARE"],
  "displayIdentifier": "unique-identifier",
  "tags": [{"key": "category", "value": "security"}]
}

Common Use Cases:

Add SBOM after release creation: When SBOM generation happens in a separate pipeline step
Add attestations: Add build attestations or signatures after the build completes
Add security reports: Attach vulnerability scans or compliance reports to deliverables
Add documentation: Attach release notes or user documentation to releases
Update existing artifacts: Add new versions of SBOMs with updated vulnerability data

Important Notes:

At least one of --artifacts, --releasearts, --deliverablearts, or --scearts must be provided
Deliverable and SCE UUIDs can be obtained from the release details in ReARM UI or API response
All artifacts are processed through rebom service for deduplication
REARM digests are generated for all BOM artifacts
Merged SBOM is automatically reconciled after artifacts are added

15. Use Case: DevOps Commands

Base Command: devops See devops documentation

16. Use Case: Probe SBOM

N.B. This use-case is currently in preview (demo-only) mode, not enabled by default in any ReARM distribution.

This use case submits an SBOM file to ReARM for security probing via Dependency-Track. The command is asynchronous: it submits the SBOM, then polls every 10 seconds until probing is complete, displaying a spinner in the meantime.

On completion, integer security metrics are printed as JSON. Use --debug true to print the full metrics payload including strings, booleans, and vulnerability/violation/weakness details.

Sample command:

rearm-cli probesbom -i $APIKEY_ID -k $APIKEY_SECRET -u $REARM_URI \
  --infile sbom.json

With optional component and branch scope:

rearm-cli probesbom -i $APIKEY_ID -k $APIKEY_SECRET -u $REARM_URI \
  --infile sbom.json \
  --componentuuid $COMPONENT_UUID \
  --branchuuid $BRANCH_UUID

Flags:

-i - API Key ID (required).
-k - API Key Secret (required).
-u - ReARM server URI (required).
--infile - Path to the SBOM file to probe (required). Supports CycloneDX and SPDX formats.
--componentuuid - Component UUID to scope the probing run (optional).
--branchuuid - Branch UUID to scope the probing run (optional).
-d / --debug - Set to true to print the full metrics JSON including all string, boolean, and nested vulnerability/violation/weakness details (optional, default false).

Normal output (integer fields only):

{
  "critical": 2,
  "high": 5,
  "medium": 12,
  "low": 3,
  "unassigned": 0,
  "vulnerabilities": 22,
  "vulnerableComponents": 8,
  "components": 134,
  "suppressed": 1,
  "findingsTotal": 22,
  "findingsAudited": 0,
  "findingsUnaudited": 22,
  "inheritedRiskScore": 47,
  "policyViolationsTotal": 0
}

Fields with null values are omitted from the normal output.

Debug output includes the complete DependencyTrackMetrics object with all fields, including dependencyTrackFullUri, submission status, scan timestamps, and full vulnerability/violation/weakness details with aliases and severity sources.

17. Use Case: Download Artifact

N.B. This use-case is currently in preview (demo-only) mode, not enabled by default in any ReARM distribution.

Download an artifact from ReARM to a local directory. By default downloads the processed BOM artifact; use --raw to download the raw (unprocessed) artifact instead.

The output filename is taken from the Content-Disposition header returned by the server. Use --outfile to override it with a custom filename.

Sample command:

rearm-cli downloadartifact -i $APIKEY_ID -k $APIKEY_SECRET -u $REARM_URI \
  --artifactuuid $ARTIFACT_UUID \
  --outdirectory ./downloads

Download raw artifact with a custom filename:

rearm-cli downloadartifact -i $APIKEY_ID -k $APIKEY_SECRET -u $REARM_URI \
  --artifactuuid $ARTIFACT_UUID \
  --outdirectory ./downloads \
  --raw --outfile my-sbom.json

Download a specific artifact version:

rearm-cli downloadartifact -i $APIKEY_ID -k $APIKEY_SECRET -u $REARM_URI \
  --artifactuuid $ARTIFACT_UUID \
  --outdirectory ./downloads \
  --version 2

Flags:

-i - API Key ID (required).
-k - API Key Secret (required).
-u - ReARM server URI (required).
--artifactuuid - UUID of the artifact to download (required).
--outdirectory - Path to the directory where the file will be written (required). Created automatically if it does not exist.
--outfile - Override the output filename (optional). Default is the filename from the server's Content-Disposition header.
--raw - Download the raw (unprocessed) artifact instead of the processed BOM (optional, default false).
--version - Specific artifact version to download (optional, default is latest).
-d / --debug - Set to true to print the resolved URL, Content-Disposition header, and filename (optional).

Output: Prints the full path of the written file on success.

18. Use Case: Register PullRequest with ReARM

Base Command: pullrequest

Subcommand group for managing first-class PullRequest entities. Currently exposes a single upsert subcommand.

`rearm pullrequest upsert`

Registers (or refreshes) a first-class PullRequest entity in ReARM, keyed by (targetVcsRepository, identity). Designed to be called unconditionally on every pull_request CI event so the PR row exists regardless of whether a release is also being created on the same commit.

This sidesteps the push/pull_request race that breaks the inline --pr-* flags on addrelease / getversion: GitHub fires both events for the same head commit, and whichever event creates the release first sees DO_BUILD=true and registers the PR; the other sees DO_BUILD=false and never runs the inline upsert. With pullrequest upsert you call the registration explicitly, before the DO_BUILD check, so the PR is always recorded.

The upsert is idempotent on (targetVcs, identity) — safe to call multiple times per CI run (e.g. once per component in a monorepo).

Sample command (FREEFORM key, vcsUri path):

docker run --rm registry.relizahub.com/library/rearm-cli \
    pullrequest upsert \
    -i freeform_api_id \
    -k freeform_api_key \
    -u https://demo.rearmhq.com \
    --identity 42 \
    --state OPEN \
    --vcsuri https://github.com/example/repo \
    --repo-path backend \
    --commit a1b2c3d4e5f6 \
    --title "Add user authentication" \
    --source-branch-name feature/auth \
    --target-branch-name main \
    --endpoint https://github.com/example/repo/pull/42

Sample command (COMPONENT key — component is implicit):

rearm pullrequest upsert \
    -i component_api_id \
    -k component_api_key \
    -u https://demo.rearmhq.com \
    --identity 42 \
    --state OPEN \
    --commit a1b2c3d4e5f6

Allowed API key types: COMPONENT, FREEFORM (with appropriate scope — org-wide WRITE or COMPONENT scope on the target), or ORGANIZATION_RW. Other ORGANIZATION_* (read-only) types are rejected.

Key type	How target VCS is resolved
`COMPONENT`	Implicit — the key identifies its component. `--component` / `--vcsuri` are not needed (and `--component` must match the bound component if supplied).
`ORGANIZATION_RW` / `FREEFORM`	Supply either `--component <uuid>` or `--vcsuri` (+ `--repo-path`). When both are present, `--component` wins.

Flags:

-i - API Key ID (required).
-k - API Key Secret (required).
-u - ReARM server URI (required).
--identity - SCM-side identity of the PR / MR / change-list (required, string). GitHub PR numbers ("42"), GitLab MR iids, Gerrit change-ids — all flow through the same flag. Identity is opaque to ReARM; uniqueness is enforced jointly with the target VCS repository.
--state - PR state (required). Supported values: OPEN, CLOSED, MERGED.
--component - Component UUID (optional). Required for ORG_RW/FREEFORM keys when not using --vcsuri. Not needed for COMPONENT keys (component is implicit). Mutually exclusive with --vcsuri.
--vcsuri - VCS repository URI (optional). For ORG_RW/FREEFORM keys when --component is not supplied. The repo is auto-created in ReARM if it doesn't already exist. Not used by COMPONENT keys.
--repo-path - Repository path for monorepo components (optional, used with --vcsuri).
--vcs-display-name - Display name for the VCS repository (optional, used with --vcsuri when auto-creating).
--commit - Commit SHA (optional). When the SCE for (targetVcs, commit) already exists, the PR head is advanced to that SCE in the same call. When the SCE doesn't exist yet, the PR row is registered without a head; the subsequent addrelease call (which carries the same --pr-* flags) advances the head once the SCE is persisted.
--title - PR title (optional).
--source-branch-name - Source branch name (optional, the branch the PR is being merged from).
--target-branch-name - Target branch name (optional, the branch the PR is being merged into, e.g. main).
--endpoint - URL of the PR in the upstream SCM (optional).

CI guidance: call pullrequest upsert from your CI workflow on every pull_request event, before any release-creation step. The standard rearm-actions initialize step does this automatically (see the PR registration step) — no extra wiring needed if you use the action.

Development of ReARM CLI

Adding dependencies to ReARM CLI

Dependencies are handled using go modules and imports file is automatically generated. If importing a github repository use this command first:

go get github.com/xxxxxx/xxxxxx

You then should be able to add what you need as an import to your files. Once they've been imported call this command to generate the imports file:

go generate ./internal/imports

Name		Name	Last commit message	Last commit date
Latest commit History 264 Commits
.github/workflows		.github/workflows
bom_samples		bom_samples
cmd		cmd
docs		docs
internal/imports		internal/imports
schema		schema
test_data		test_data
tests		tests
.dockerignore		.dockerignore
.gitattributes		.gitattributes
.gitignore		.gitignore
Dockerfile		Dockerfile
Dockerfile.exec		Dockerfile.exec
LICENSE		LICENSE
README.md		README.md
build.sh		build.sh
go.mod		go.mod
go.sum		go.sum
main.go		main.go
trigger_build		trigger_build

Folders and files

Latest commit

History

Repository files navigation

ReARM CLI

Download ReARM CLI

Authentication

Table of Contents - Use Cases

1. Use Case: Get Version Assignment From ReARM

2. Use Case: Send Release Metadata to ReARM

3a. Use Case: Check If Deliverable Hash Already Present In Some Release

3b. Use Case: Get Release By Version

4. Use Case: Request Latest Release Per Component Or Product

5. Use Case: Persist ReARM Credentials in a Config File

6. Use Case: Create New Component in ReARM

7. Use Case: Synchronize Live Git Branches with ReARM

8. Use Case: Add Outbound Deliverables to Release

9. Use Case: xBOM Utilities

10. Use Case: Finalize Release After CI Completion

11. Use Case: Transparency Exchange API (TEA) Commands

12. Use Case: Oolong TEA Server Content Management Commands

13. Use Case: VCS-based Component Resolution

13.1: Creating Components

13.2: Getting Versions

13.3: Adding Releases

13.4: Monorepo Support

14. Use Case: Add Artifacts to Existing Release

Simple Mode: Add Artifacts to Release

Advanced Mode: Add Multiple Artifact Types

Add Artifacts to Deliverable Only

Add Artifacts to Source Code Entry Only

15. Use Case: DevOps Commands

16. Use Case: Probe SBOM

17. Use Case: Download Artifact

18. Use Case: Register PullRequest with ReARM

rearm pullrequest upsert

Development of ReARM CLI

Adding dependencies to ReARM CLI

About

Topics

Resources

License

Uh oh!

Stars

Watchers

Forks

Releases 9

Contributors

Uh oh!

Languages

`rearm pullrequest upsert`