sign-artifact

Sign Artifact

Add an Artifact Signing (SscaArtifactSigning) step to an existing Harness pipeline. The step retrieves an artifact from a registry or local workspace, signs it with Cosign, and optionally pushes the .sig signature file back to the registry.

This skill only works with existing pipelines — do not create standalone signing-only pipelines.

Prerequisites: Container images must be built and pushed (or available in registry) before signing. Key-based signing requires Cosign key pair file secrets (/create-secret). Harness docs note that Deploy-stage signing is not yet supported — prefer CI or Security stages.

Guide the user through a step-by-step interactive wizard (same UX as /verify-sign):

• Wizard: references/interactive-wizard-flow.md
• UI ↔ YAML: references/artifact-signing-step.md
• CD note: references/cd-containerized-step-group.md

Interaction model (mandatory)

1. One question per turn — use AskQuestion when available; otherwise numbered options with (Recommended).
2. Opening message — add Artifact Signing after build/push; mention keyless, key-based, Vault, and HAR.
3. Progress breadcrumb — after pipeline fetch: Pipeline · Placement · Source · Details · Signing · Upload · Submit
4. Record answers — running summary; do not re-ask unless the user changes direction.
5. Fetch before configure — harness_get before placement/source questions.
6. Show pipeline structure — highlight build/push and existing SscaArtifactSigning steps.
7. Infer connector from build/push — skip connector question when unambiguous from YAML.
8. Never guess image tags — always ask for image in Phase 7.
9. Confirm before write — summary + harness_update only after user confirms.
10. Stop after update — after successful harness_update, provide a configuration summary and point the user to /run-pipeline to execute. Do not call harness_execute, poll executions, or run harness_diagnose in this skill (same pattern as /configure-repo-scan).
11. Phase 3 Placement is mandatory — always run Phase 2 then Phase 3.
12. Sequential with SBOM/SLSA — if SscaOrchestration or provenance exists, place signing after those steps sequentially (Cosign registry race).
13. Offer all three source tiles — Third-Party, Harness Artifact Registry (HAR), and Harness Local Stage (HAR is supported in YAML even when the UI screenshot shows only two tiles).
14. Existing signing step — if SscaArtifactSigning already exists, ask: update in place, add a second step, or abort. If existing step has uploadSignature.upload: false (or block missing) and user wants .sig in registry, set upload: true.
15. Upload .sig defaults OFF in Harness — UI checkbox Attach signature to Artifact Registry is unchecked by default. For container images, always set uploadSignature.upload: true unless the user explicitly opts out. Confirm this in Phase 9 and in the submit summary.
16. Verify .sig after run — when upload is enabled, after the user runs via /run-pipeline, check step logs for signature push success; see Troubleshooting if registry shows no signature tag.
17. List all connectors before Phase 6 — never show a hand-picked subset. Call harness_list with filters: { type: "<ConnectorType>" } and size: 100 at project, org, and account scope; merge and present every match in AskQuestion. See references/interactive-wizard-flow.md Phase 6.
18. Add CI failureStrategies on update — when inserting signing into a CI stage, ensure the stage has failureStrategies with MarkAsFailure (not Ignore). Missing or Ignore hides signing failures as IgnoreFailed while the pipeline continues.
19. Warn when no build/push step — if the pipeline has no image build/push step, warn that signing will target a pre-existing registry image; confirm the tag exists and was pushed before signing.
20. Surgical YAML only — harness_update must start from the exact yamlPipeline returned by harness_get in this session. Insert or update only the SscaArtifactSigning step (and CI failureStrategies if required). Never add, remove, or reorder other steps. Never add HarnessSAST, HarnessSCA, STO scanners, or /configure-repo-scan steps — use those skills only when the user explicitly asks for code/container scanning.