Versions and delivery status
Create a version from a finished release, request a test deployment, read its status and evidence, accept or reject the test, and understand what production approval does and does not do.
- Availability: Experimental
- Evidence: Read from source
- How-to guide
Before you start
- A planned release must read Results accepted · ready for a version: every result in its scope was accepted.
- You need the full commit hash of what should be tested: all 40 hexadecimal characters.
- You need the permission Take decisions.
- The project's delivery workflow, test address and services are configured by the person who operates the installation, under Infrastructure. A delivery worker must be enabled and running for a request to be carried out.
Four words that are not the same
| Word | On this page it means | It does not mean |
|---|---|---|
| Request | You chose Request test deployment. A frozen publication request exists | That anything was sent to GitHub |
| Approval | A person recorded a decision: the scope, the test result, or production | That anything ran |
| Dispatch | The worker sent the request to the provider | That the provider finished, or even started |
| Verified completion | The run was observed to finish and the expected evidence of every component was read and matched | Only that a workflow was green |
The interface keeps them apart, and so does every status below. The work status vocabulary has the full definitions.
Create a version
- Open Versions ("Test a specific version."). "A version binds a completed planned release to a full commit hash."
- In Create a version, fill in Version name, choose the Completed planned release, and paste the Full commit hash ("All 40 hexadecimal characters.").
- Choose Create version.
Expected outcome: the version appears as Version prepared, with "From {name}" and the hash.
| You see | Meaning |
|---|---|
| "A planned release appears here once every result in its scope is accepted." | No release is finished yet |
| "Enter the complete 40-character commit hash." | A short hash was pasted |
| "Every result in the planned release must be accepted first." | A result is still open |
| "Authorize correction work for the rejected version before preparing a replacement." | You are replacing a rejected version: authorize the correction first. The new version then shows "Replaces the rejected version {name}" |
Request a test deployment
On a Version prepared, choose Request test deployment.
Expected outcome: the version reads Test deployment requested, and an attempt appears under it. The panel reminds you: "The queue needs a connected worker. Requesting publication does not mean it has been published."
The request freezes what was approved: the repository, the branch, the workflow, the revision, the destination, the list of components and the evidence that will be required. Open Approved publication configuration on the attempt to read it, with its identifier. Settings changed later cannot redirect a request that was already made.
Only one test publication runs per project at a time: "A test publication is already in progress for this project."
Read the status of an attempt
Each attempt shows a state, a sentence and, once it exists, View run.
| State | Sentences you may see | Meaning |
|---|---|---|
| Queued | "Waiting for the deployment worker." | Requested. Nothing was sent yet |
| Running | "Checking the branch and workflow.", "Dispatch started.", "The workflow is running.", "Waiting for environment approval in GitHub." | Dispatched, not finished. An environment approval happens in GitHub, not here |
| Completed | "The workflow completed." | The run finished and its evidence was read. The version reads Test workflow completed |
| Failed | "The workflow failed." or a specific reason | The run failed, or a check refused it before anything was deployed, for example "The branch moved after this version was approved. Nothing was deployed." |
| Needs attention | "The dispatch outcome is unknown. Identify its GitHub run before continuing." | Delegate does not know whether a run exists. See reconciliation |
Evidence
Under the attempt, each component of the application is listed with a state (Verified, Unverified or Missing), a detail and, when available, a digest. This is what the protected workflow reported about what it built and deployed; Delegate checks that it belongs to this exact run, attempt and revision. It is not an independent test of the running application.
With the evidence profile that only reports the workflow result, components stay Unverified, and such a version cannot be approved for production.
Accept or reject the test
When the version reads Test workflow completed:
- Choose Open test application and check the change yourself. View run and logs opens the run.
- Decide:
- Accept: write What did you verify? and choose Accept test result. The version reads Test accepted, with "Test accepted by {actor}".
- Reject: open The test deployment failed verification, write What failed? and choose Reject test result. "Rejecting ends this version: it can never be approved for production. A corrected revision becomes a new version."
A workflow that completed is not a test that passed. Only your decision moves the version forward.
When the outcome is uncertain
An attempt in Needs attention (or Failed) offers a form to resume verification of a run that already exists. It appears in Needs my attention as Test publication needs attention.
- Open the repository's Actions page at GitHub and find the run that matches this version.
- In Delegate, fill in GitHub run number from its URL and What did you verify?.
- Choose Resume verification. "Enter the existing GitHub run. This resumes verification without starting another deployment."
Expected outcome: "Verification resumed for the existing run.", and the attempt continues from observing that run. The action is recorded with your note. It never dispatches a workflow, changes source, retries a failed deployment or creates a resource.
| You see | Meaning |
|---|---|
| "That run does not match the approved repository, workflow, branch and revision." | It is a different run. Nothing was changed |
| "That run started before this publication request." | It cannot be the run of this request |
| "Use the numeric run identifier at the end of its GitHub URL." | The value is not a run number |
| "This operation changed while you were reviewing it. Refresh and review it again." | The attempt moved on while the form was open, for example the worker found the run. Refresh; you may have nothing left to do |
| "One or more component artifacts are missing. Review the run before resuming verification." | The run finished without all its evidence |
| "This older operation has no verified approval snapshot. Create a reviewed replacement." | The request predates frozen approvals and cannot be resumed |
Production
On a version that reads Test accepted, the panel says: "Approval requires verified evidence for every component. This records approval of the tested version; production execution is not connected."
- Write an Approval note.
- Choose Approve for production.
Expected outcome: the version reads Production approved · execution pending, with "Production approved by {actor}. Execution is not connected; nothing was published."
Approval is refused with "Verify every component artifact before approving production." when any component is not Verified, and with "The approved revision does not match this version." when the hash differs.
Limits
Next action
If the test was rejected, authorize correction work and prepare a new version. If something is stuck, see Delegate recovery.
Related: Work status vocabulary · External work · Supported limits