A generic gate resource for Concourse CI.
Allows you to model quality gates and pipeline control flow.
This resource is backed by a Git repository and wraps git-resource.
A public container build of this repo is available at ghcr.io meshcloud/gate-resource.
Contributors Welcome: This resource is new and hot off the press. We welcome your feedback and contributions!
To see an example pipeline using gate-resource, head over to gate-resource-example.
.
├── my-gate
│ ├── 1
│ └── 2
└── my-autogate
├── a
└── b.autogate
note: The gate repository is currently append-only. Files are not expected to be deleted or cleaned.
The gate-resource supports two types of gates: simple-gates and auto-gates.
Each folder in the repository represents a gate. Files in each gate-folder represent items that successfully passed the gate. The files may be empty or contain any metadata that you whish to track. In the example above, my-gate
is a simple-gate
Auto-gates are gates that automatically close depending on items passing through other gates. An auto-gate contains .autoclose
items, which is a simple text file that contains dependant items, one on each line ("autoclose spec"). For example, b.autoclose
depends on these two items passing through my-gate
:
my-gate/2
my-gate/3
# metadata after this line
arbitrary content goes here
When all dependant items passed, the autoclose item closes and drops the .autoclose
extension from its filename. Autoclose files can also contain additional metadata. To separate the autoclose spec from additional metadata, gate-resource looks for a line starting with #
and stops interpreting any lines after this.
Unfortunately Concourse does not support emitting an empty set of versions from out
. However, this is necessary for gate-resource as it may not find any autoclose items to close in a particular update. As a workaround, gate-resource emits the none
version. in
will no-op on encountering this version.
Since concourse detects that the none
version already exists after the first time it's generated, it will only trigger a single build when an auto-gate is used with trigger: true
. You can detect that the none
version was fetched when no passed
and metadata
files were created by the get
step (see below).
git
: Required. Configuration of the repository. Supports the following subset of git-resource configuration options (review the link for descriptions)- Required:
uri
,branch
,private_key
- Optional:
git_config
,short_ref_format
,
- Required:
gate
: Optional. The gate to track.
The repository is cloned (or pulled if already present), and any commits made to the specified gate
from the given version on are checked for items passing through the gate.
note: If you want to ensure the resource triggers for every item that passed the gate, use the resource with
version: every
Outputs 2 files:
passed
: Contains the name of the item that passed the gatemetadata
: Contains the contents of whatever was in your gate item. This is useful for environment configuration settings or documenting approval workflows.
note: the git repository cloned during
in
is a shallow clone and does not track an upstream branch. This is not a problem when using theout
step to create or update gates.
Performs one of the following actions to change the state of a gate.
One of the following is required.
item_file
: Path to a file containing an item to pass through the gate. Wildcards are allowed, but should match only a single item. This file may also be a.autogate
file.update_autoclose
: Process pending autoclose items in the repository
Note: Gate puts are idempotent. When putting a new gate item or
.autoclose
spec, the resource checks if a matching item already passed the gate. When this is the case,out
will emit the version that previously produced this item.
.autoclose
items can be put to the gate just like regular items. However, the version that gate-resource will emmit for this item may vary:
- when a matching target item (i.e. the filename without
.autoclose
extension) already exists, emits the version that produced this target item. - when the
.autoclose
item is immediately closable (all dependent items alreday passed their gates), close the item and emit the version - otherwise emit a
none
version (see above)
- docker is required - version 17.06.x is tested; earlier versions may also work.
The tests have been embedded with the Dockerfile
; ensuring that the testing
environment is consistent across any docker
enabled platform. When the docker
image builds, the test are run inside the docker container, on failure they
will stop the build.
Run the tests with the following command:
docker build -t gate-resource .