RFC: Projects

[vito]

Rendered

Please comment on individual lines, not at the top-level.

TODO:

• flesh out cross-pipeline passed constraints - it's only mentioned in passing

[jchesterpivotal]

I'd suggest the taskdir style: task: foo would be interpreted by default as project-name/tasks/foo/task.yml.

The basic reasons are that tasks can grow large and complex in their own right, so establishing subdirectories in advance saves messy top-level task directories. It's also easier to do things in bulk (eg, use xargs to update multiple task YAMLs simultaneously).

[vito]

Following the discussion in #31 (comment), I've added an open question: "Can Projects replace Teams?". Really interested in hearing feedback on this idea. 🙂

[c4lliope]

I usually consider the phrase "project" to be as ambiguous as can be; it gives a vague sense of a user's underlying goals, though offers no indication of what they could be, and in many places and programs is used only to convey a sense that you can draw a clean boundary around a group of resources.

Accordingly - could you consider renaming the "project" idea, using "scope" or "namespace" (as you describe in this line). Perhaps "codebase" could do also, if they are usually to be tied to a git repository like the example suggests.

"Scope", "Namespace", "Space", "Codebase"... - also clearly indicate clean boundaries around your included resources and jobs, but they don't imply as much of an underlying goal as "project" seems to, which leaves room for them to change into a more flexible programming model.

As Naming is a hard problem, please use care in choosing a good, clearly-explained name for the ideas that this RFC introduces. As you say, this will likely be the opening concept by which new users learn the workings of Concourse; making a solid choice here could set you apart from similar programs, in terms of how you (and your users) organize mechanical jobs in general.

Nice proposal; much obliged.

[mvdkleijn]

Please don't? 😄

We use the Teams concept to map onto our product teams. The term "project" is considered a legacy, non-agile term. As such, the first question replacing Teams by Projects would raise in our organization is: "It no longer supports agile organizations?" (I know, I know... still...) We barely convinced people that agile is good and barely got people used to product teams, etc.

I was kinda hoping Projects would become an organizational tool under Teams for housing related Pipelines. I.e. you'd have a Team like "Tasty Treats app" which could have Projects like "Strawberry Icecream", "Bubble Tea" and "Apple Pie" with Pipelines underneath those related to the various tasks and builds that need doing there.

But feel free to ignore my monologue. Just dropping my 2 cents. 😄

[c4lliope]

I had a go renaming the ideas in your proposal as "pipeline plan",
each one undergoing a "build phase".
The idea really gains some legs, because the only required keys
inside your .yaml are name: and plan:.

Here is my copy rendered.
I keep all logical ideas in place and only change the proposal's project labels.

[fshuva]

Hi,
I was wondering if there are any plans to add variables in the set_pipeline name. If someone wants to use dynamically named pipelines, the only way to do it currently is using a shell script with fly. If we had vars support in the pipeline name, it would be easier to create dynamic pipelines based on passed variables.

[dR3b]

hi@all Are you still working on this?

[taylorsilva]

I'm closing this RFC as there's currently no plan to work on this. Community interest seems high, but I don't have any interest in implementing this anytime soon.

Anyone is free to re-submit this idea as an RFC again if they have the motivation to see the RFC through.