Skip to content

Publisher ​

Publish a workflow to make it available for reuse through the Verdog catalogue. Each release refers to a workflow at an exact Git commit. Publication requires repository control and a Verdog seat; see Permissions.

Offers ​

A published workflow release is called an offer. It identifies the source repository, full commit hash, and workflow, and includes a description, Python package name, graph preview, repository dependencies, and Python requirements. The workflow's input and output Python types are available in its source.

Preparing a release ​

Before publishing a workflow:

  1. Use Verdog: Check to validate the project.
  2. Include a README describing the workflow's purpose, inputs, outputs, and requirements.
  3. Commit and push the workflow and its dependency pins to GitHub.
  4. Ensure that intended readers can access every required repository.

A release requires a clean working tree and a commit on a known remote branch. The hosted catalogue stores the workflow's description, graph, and dependency information; the workflow source remains in your repository.

Visibility ​

A release inherits the visibility of its source repository. Releases from public repositories are visible to signed-in catalogue users. Releases from private or internal repositories are visible to users who can read the repository on GitHub. No separate catalogue-sharing list is required.

For a public release, every declared repository dependency must also be public and accessible through your GitHub authorization. Publication fails if a declared dependency is private or inaccessible; the error identifies the repository. Rejected GitHub authorization and temporary provider failures are reported separately, so they can be resolved before retrying publication.

Include all required dependencies before publishing. The catalogue checks the submitted dependency list, but does not fetch the source to verify that the list is complete. Readers need access to every dependency to inspect or import the workflow. Commit pins do not guarantee that a repository will remain public or that a commit will remain available.

Releases ​

Publishing a new commit creates a separate release. Republishing the same repository, commit, and workflow updates its catalogue metadata and restores it if it was retracted. It preserves the source commit and original publication date.

The catalogue displays the newest visible release for each repository and workflow. Use Verdog: Browse Published Workflows to find a workflow and select a release to read its exact metadata. The Exact published release selector identifies each available release by its commit and publication date.

Non-retracted releases remain importable by commit after they leave the recent release list. Publishing a new release does not update existing consumers' dependency pins.

Retraction ​

Retracting a release removes it from catalogue listings and future imports. Retraction requires admin or maintain permission on the source repository; a Verdog seat is not required. It does not delete source code, remove existing dependency pins, or prevent the use of previously fetched checkouts.