Skip to main content

Synopsis

Report a jira attestation to an artifact or a trail in a Kosli flow.
Parses the given commit’s message, current branch name or the content of the --jira-secondary-source argument for Jira issue references of the form: ‘at least 2 characters long, starting with an uppercase letter project key followed by dash and one or more digits’.
Matching is case-insensitive: proj-42 and PROJ-42 in a commit message are both recognised and returned as PROJ-42. Any token that matches the Jira key format (a word boundary, two or more letters/digits starting with a letter, a dash, and one or more digits) is treated as a candidate, regardless of whether it is an intentional Jira reference. For example, a commit message see note-1 for context, fixes PROJ-42 will look up both NOTE-1 and PROJ-42 in Jira. If NOTE-1 does not exist, the attestation will be non-compliant even though PROJ-42 is valid. Use --jira-project-key to restrict matching to one or more known project keys and avoid unintended candidates. Any candidate match is automatically excluded if every occurrence in the parsed text is immediately followed by a hyphen and a digit — for example, CVE-2026-41284 is excluded because CVE-2026 would be followed by -4. This applies across all parsed sources (commit message, branch name, and secondary source). Note: if your Jira project key collides with this pattern (e.g. a project key of CVE), an issue reference that happens to be the prefix of a longer hyphenated number (such as a CVE identifier) will be filtered out. Use --jira-secondary-source with a different identifier format as a workaround. If you want to restrict the Jira issue matching to a specific project, use the --jira-project-key flag to specify your own project key. You can specify multiple project keys if needed. If the --ignore-branch-match is set, the branch name is not parsed for a match. The found issue references will be checked against Jira to confirm their existence. The attestation is reported in all cases, and its compliance status depends on referencing existing Jira issues. A reachable but wrong base URL still surfaces as a non-existent issue, because Jira answers 404 both for an issue that does not exist and for one you may not view. A base URL that cannot be reached is reported as not confirmed, with the transport error as the reason. A credential rejection is likewise detected and reported as not confirmed, with a warning identifying the credentials. Use --debug to see the status Jira returned per issue. The --jira-issue-fields can be used to include fields from the jira issue. By default no fields are included. *all will give all fields. Using --jira-issue-fields "*all" --dry-run will give you the complete list so you can select the once you need. The issue fields uses the jira API that is documented here: https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-issues/#api-rest-api-2-issue-issueidorkey-get-request The attestation can be bound to a trail using the trail name. The attestation can be bound to an artifact in two ways:
  • using the artifact’s SHA256 fingerprint which is calculated (based on the --artifact-type flag and the artifact name/path argument) or can be provided directly (with the --fingerprint flag).
  • using the artifact’s name in the flow yaml template and the git commit from which the artifact is/will be created. Useful when reporting an attestation before creating/reporting the artifact.
To specify paths in a directory artifact that should always be excluded from the SHA256 calculation, you can add a .kosli_ignore file to the root of the artifact. Each line should specify a relative path or path glob to be ignored. You can include comments in this file, using #. The .kosli_ignore will be treated as part of the artifact like any other file, unless it is explicitly ignored itself. You can optionally associate the attestation to a git commit using --commit (requires access to a git repo). You can optionally redact some of the git commit data sent to Kosli using --redact-commit-info. Note that when the attestation is reported for an artifact that does not yet exist in Kosli, --commit is required to facilitate binding the attestation to the right artifact. To record repository information, all three of --repo-id, --repo-url, and --repository must be set together. These are automatically set in GitHub Actions, GitLab CI, Bitbucket Pipelines, and Azure DevOps. In other CI systems, set them explicitly to capture repository metadata.

Flags

Flags inherited from parent commands

Examples Use Cases

These examples all assume that the flags --api-token, --org, --host, (and --flow, --trail when required), are set/provided.
Last modified on August 30, 2026