Skip to main content
View Markdown ↗

Copy this page

Select and copy the Markdown below, then paste it into your LLM.

From missing evidence to a delivered push

Record the required evidence, push through the gate, and confirm delivery for the same commit.

Jump to the written guide ↓

Follow along

Goal: record evidence for one commit, push through Pushgate, and confirm delivery. The test-policy example uses a repository with a check already required. New repositories can start with a metadata-only baseline; that baseline does not run tests.

Before you start

  • Install CI/lock 4.5.0 or later, and have Git and a disposable repository you can push to.
  • Complete repository setup. Use its generated remote and enrollment instructions; do not copy the demonstration's repository or identity.
  • A signed-in human must approve enrollment and any repository policy assignment. An agent can prepare the configuration and explain it.
  • Run the following in the repository. Keep the commit unchanged between recording evidence and pushing.

1. Confirm the principal and commit

cilock version
cilock agent status
git status --short
git rev-parse HEAD
git remote get-url origin

Expected: the agent has its own usable signing identity, and origin is the Pushgate remote supplied by setup. Stop if enrollment is incomplete or the remote points directly to your Git host.

2. Record the required evidence

For a newly connected repository using default protection:

cilock attest --step push-metadata -a git -a alps-evidence

Expected: one signed collection containing Git evidence and agent observations for the current commit. This command does not run a build, test, or scan.

For a test-policy workflow, use the command and step name generated for your repository's active policy. For example, a Go repository whose policy requires the test step can run:

cilock run --step test -- go test ./...

Expected: the required command finishes successfully and its evidence is recorded. A different step name, signer, subject, or policy requirement can still cause refusal. Do not substitute this example for the repository's instructions.

3. Push and wait for delivery

This changes the selected remote branch. Use your disposable branch for the exercise.

git push origin HEAD
cilock pushgate status --remote origin --wait

Expected: delivery is confirmed for the same commit from step 1. Accepted or queued is not yet delivered. If the push is refused, follow its missing requirement and next action, then retry without weakening the policy.

4. Inspect the decision

Open the repository's Pushgate policy and activity pages. Compare the commit, repository, evidence step, and selected immutable policy release. If this was the first push with default protection, a human must choose additional checks or explicitly keep default protection before the next distinct push.

Troubleshooting and cleanup

If you amended the commit, record fresh evidence. If the command passed but the push failed, inspect the policy decision rather than treating a successful test as a complete gate verdict. Preserve the delivery record, then remove the disposable branch through your normal repository process. Do not remove required protections from a shared repository.

Next: inspect the refusal cases or manage gates in the platform.

Browse the other walkthroughs