Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prototypes #5719

Open
matthewpereira opened this issue Jun 5, 2020 · 0 comments
Open

Prototypes #5719

matthewpereira opened this issue Jun 5, 2020 · 0 comments
Labels
product epic These meta-issues link multiple engineering issues together and contextualize initiatives. sred

Comments

@matthewpereira
Copy link

matthewpereira commented Jun 5, 2020

TLDR

  • 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.

Current Status

  • In Progress

References

concourse/rfcs#37
concourse/rfcs#38
#6540 - Add support for prototypes

See: Reinventing Resource Types

@matthewpereira matthewpereira created this issue from a note in 2020 Quarterly Roadmap (Q3 - July to September) Jun 5, 2020
@matthewpereira matthewpereira added product epic These meta-issues link multiple engineering issues together and contextualize initiatives. needs-more-info labels Jun 5, 2020
@scottietremendous scottietremendous moved this from Q3 - July to September to Q4 - October to December in 2020 Quarterly Roadmap Jul 14, 2020
@scottietremendous scottietremendous moved this from Q4 - October to December to Q1 - January to March in 2020 Quarterly Roadmap Oct 13, 2020
@scottietremendous scottietremendous added this to Q1 - January to March in 2021 Quarterly Roadmap Feb 23, 2021
@scottietremendous scottietremendous changed the title Prototypes (aka Resources v2) Prototypes Feb 24, 2021
@scottietremendous scottietremendous moved this from Q1 - January to March to Q2 - April to June in 2021 Quarterly Roadmap May 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
product epic These meta-issues link multiple engineering issues together and contextualize initiatives. sred
Projects
2020 Quarterly Roadmap
Q1 - January to March
2021 Quarterly Roadmap
Q2 - April to June
Development

No branches or pull requests

2 participants