Support multiple workflow engines: Gitlab

[mattiamatrix]

Hello everyone,

looking at projen vision document, one of the Ideas consist of supporting multiple workflow engines. Gitlab, what about it? Is it in the interest of the project to support GitLab with the same level of support given to GitHub?

I am mainly asking this because my personal adoption of projen has been impacted by the lack of full support for GitLab workflows.

I am aware of Manual release (#1938 ?), and I am sure there are many possible ways to work on GitLab.

However, as a beginner user of projen I would like to have my GitLab workflow autogenerated by the framework.

What do you think? Please correct me if I am completely wrong!

Cheer

[mrgrain]

We should do this. I reckon the tricky bit will be finding an abstraction for workflows that can be applied to multiple providers.

[agdimech]

I’ve been thinking of this and am actually in the position that we should allow these types of features to be decorated onto a simple kernel project, building the outer layers additively as component add ons.

new Project({name: “foo”}).with(new Github({defaultBranch: “main”}).with(new Typescript()).with(new CDKApp(…));

In this approach - users opt in to various features by stringing them together - allowing more tightly scoped required props and more ways to mix and match.

If a user always wanted to apply EsLint and GitHub they can simply configure them once into some type of middleware/decorator and just apply it to all their projects at creation time. For example:

const decorator = (project: Project) => project.with(
  new Github({defaultBranch: “main”}),
  new Eslint({ignorePatterns: [“bar”]})
);

new Project({name: “foo}).with(decorator);
new Project({name: “bar”}).with(decorator);

if other users wanted Gitlab, then they can configure that accordingly. And if there are certain combinations that make sense in lots of cases then we can just create default composition that people can use as is, but they always have the option of mixing and matching like lego if need be. This does assume that each component is contained and independent of one another as to not conflate concerns.

[mrgrain]

I really like the decorator API. Some initial thoughts:

• Currently all components require a project. That means we can't instantiate them and then pass them to with(). They'd always need wrapping in a function that takes a project as first argument.
• Free floating functions don't exist in jsii. So the decorator interface might have to be be an IDecorator that has a make method.
• Of course we could make components not need a project
• Or we lean into jsii save instantiate components by their jsii name (as a string). But we lose strong typing here.
• Some components aren't very pure at the moment. They require something else to be created before them to properly work. I wonder if we are missing a lifecycle event post-dependcies that's happening after the constructor but before synth. Or maybe that's just preSynth. Either way, we'll need to make components be more strict.