You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Creating a flexible new abstraction to better support reusable tasks allows application operators and application developers work with reusable, versioned pipeline elements in a way that can simplify their pipeline configuration, and allows them to perform common tasks in a more intuitive way.
Problem
Concourse's resource primitive is a powerful and flexible concept for managing with versioned pipeline inputs and outputs, but there are many cases where this breaks down in practical use.
For example, pull request resource types represent each pull request as a version so that you can use Concourse to run tests for all your PRs. This means that your build history might be pointing at different PR in each build, or you might get into weird situations because version: every allows versions to be skipped when used with passed: constraints
Build retriggering helps recreate builds for a specific PR, but only if it has already run and exists in the history. Otherwise you have to look up the right version in the git resource, pin, run, validate, and unpin to ensure that everything goes back to normal afterward.
Tasks are more flexible, but require a lot more work and verbose boilerplate to configure and maintain. Verbosity means wasting time on typos and forgetting details.
Tasks can almost be packaged up and re-used as easily as resource types, but it would be helpful to have more advanced abilities on top of this functionality
Ideally, we need something as versatile as tasks and as easy to use as resource types.
Use Cases
Workflow/infrastructure automation
Continuous Integration
Proposed Solution
Creating a new abstraction (prototypes) would help make configuring and reusing pipelines a lot easier.
Outcomes
Navigating the Concourse landscape becomes a lot easier: instead of using 'generalized resources' for spatial resources, notifications, and triggers, users would use 'prototypes' instead.
TLDR
Problem
resource
primitive is a powerful and flexible concept for managing with versioned pipeline inputs and outputs, but there are many cases where this breaks down in practical use.version: every
allows versions to be skipped when used withpassed:
constraintsUse Cases
Proposed Solution
Outcomes
Current Status
References
concourse/rfcs#37
concourse/rfcs#38
#6540 - Add support for prototypes
See: Reinventing Resource Types
The text was updated successfully, but these errors were encountered: