> - Truly a pipeline based stages. No messing around with git branches/tags for each environment release.
That's how we use it. We have two or more stages for each environment (repo upload + installation, often tests) that are simply chained.
> - Ability to combine multiple builds together.
You can do fan-in and fan-out between pipelines (you can combine multiple pipelines in a DAG).
> - Build dependencies. Ability to trigger project-B build when project-A build succeeds. (Docker Cloud Builds have something like this.)
As above, with a graph of pipelines. We use this to trigger rebuild of some projects when libraries change.
> - Use the same artifact across multiple build stages.
You can reference and retrieve artifacts from all previous stages, even stages from upstream pipelines. The syntax for referencing takes some time to get used to.
> - An option to promote a build to the next step either manually or automatically.
automatic is default, but you can have manual approval steps, optionally with permissions attached to them.
Plug: I wrote a book that uses GoCD for its examples: https://leanpub.com/deploy
It's a hybrid hosted model -you supply your own workers (they provide a CFN template to make that part easy), everything else (e.g. web UI/API) is hosted
Within a pipeline, you can 'pass' an output of one step as a triggering input to another. Across pipelines, you can use e.g. an S3 resource to save state; the job to be triggered looks at that S3 resource and triggers when it changes.
> Use the same artifact across multiple build stages.
Yep - you can pass the output of one job to be used as the input of another.
> Ability to combine multiple builds together.
Yep - have a look for "fan-in" in the docs.
> An option to promote a build to the next step either manually or automatically.
You can manually trigger steps from the UI; you could also have a resource that triggers a job automatically on some condition.
There was talk of Python + Linux support a few years back, a shame that didn't take off.
You can do Linux today actually - you can connect to machines over SSH, run bash scripts, etc. Today there's a Mono dependency, but in the next couple of weeks we'll be rolling out a beta that removes that dependency.
Python scripting support is on the roadmap - :-)
- Truly a pipeline based stages. No messing around with git branches/tags for each environment release.
- Ability to combine multiple builds together.
- Build dependencies. Ability to trigger project-B build when project-A build succeeds. (Docker Cloud Builds have something like this.)
- Use the same artifact across multiple build stages.
- An option to promote a build to the next step either manually or automatically.
Amazon's internal Apollo system was amazing. AWS Code Pipelines kind of does some of these things but it's every limited and hard to work with.