What would your ideal version of .gitlab-ci.yml look like? (As generic as possible)

[pmcmaw]

We are aware that it seems we had more community members using .gitlab-ci.yml than we expected. Currently with not using this functionality we are unsure what the most desirable (but also generic) .gitlab-ci.yml may look like. I have opened this discussion in the hope we get enough conversation and agreement on what people would want this to look like so think about bringing it back.

The reason I am asking for it to be generic is so that everyone can consume it.

[jcpunk]

I'd like something to run pdk validate and pdk test unit. For my usage, I'd prefer to not bother with the unit tests if validate fails, but others may disagree.

[TheMeier]

I think think running tests sequentially from less expensive to more expensive is a common practice ie. static checks (validate) -> unit -> acceptance is a common practice

[willmeek]

There are CI examples and templates in the GitLab docs, if this is helpful

https://docs.gitlab.com/ee/ci/examples/

[pmcmaw]

Long time no see @willmeek - thank you for this! 🥳

[cruelsmith]

As generic as possible

One big difference between Github actions as GitLabCI is that you can not add jobs once the pipeline is already defined. So it will not really possible to use something like matrix_from_metadata_V2 to generate the Matrix for each Puppet version and OS version from the Metadata to then run the tests.
At least that is my current knowledge.

That is why i vote to focus on the validation and spec tests support only. Since for the Ruby and Puppet version an Matrix via the config_defaults.yml can be maintained via PDK. This allows overrides via the local .sync.yml in the project when needed.
Not possible would be an OS version matrix for the acceptance tests since each project is to different and there should be only one source of truth for that one.

Would also vote against the usage of pdk * command for the GitLabCI since also the Github workflows don't use these but the rake rake tasks directly. That would also eliminate am required special docker image with PDK or the installation of it.

Feal free to look and (re-)use my version of the GitLabCI:

• https://gist.github.com/cruelsmith/3a5214730d1abb1ec4ebd3d01215c89f
• https://github.com/pixelpark/pdk-custom-templates/blob/8688368c7d642e614c3bd23a8cdcdac45e9d648e/moduleroot/.gitlab-ci.yml.erb + https://github.com/pixelpark/pdk-custom-templates/blob/bc00a806d961c0c4c4c99a0d11da2d325987df53/config_defaults.yml#L581-L598

[cruelsmith]

One big difference between Github actions as GitLabCI is that you can not add jobs once the pipeline is already defined. So it will not really possible to use something like matrix_from_metadata_V2 to generate the Matrix for each Puppet version and OS version from the Metadata to then run the tests. At least that is my current knowledge.

Oh that is not be right. GitLabCI has Dynamic child pipelines. This could maybe used to create the jobs for the Puppet version and OS version matrix.

[willmeek]

Bit of a hacky example of a Dynamic child pipeline - https://gitlab.com/gitlab-org/quality/ci/secure-test-project-orchestrator/-/blob/master/.gitlab-ci.yml?ref_type=heads#L42

Though it might not be a generic simple example.

[Dan33l]

@cruelsmith thank you for your Dynamic child pipeline example . I am starting to use more or less same.

And i would like to be happy to get this. More or less i just added Beaker acceptance tests in my Gitlab CI file

[TheMeier]

The drawback of child pipelines is that they are dedicated separate pipelines. This can be an issue for builtin notifications and webhooks for example.

[cvquesty]

I like having the .gitlab-ci.yml automatically created for me. My runners pick it up when I push a new rev. It would be nice to start settling on what acceptance testing looks like (officially, I man), and to lay out a simplistic WORKING example (whether Beaker or Litmus) and to communicate heavily which is the choice.

My concern is never with the quality and suitability of products. You Puppet folks are super awesome on that end.

My concern almost always revolves around clear, concise documentation (see the current state of PuppetDB installation documentation for reference). I think a lot of mileage would be gained in both beginner and advanced topics if a "runbook" strategy was enjoined across the product line.

[kenyon]

What was there before seemed to work fine for my usage on gitlab.com.

[Dan33l]

@pmcmaw Thank you Paula for opening this discussion. Are you waiting some/more inputs ?

[danmetzler]

I would echo that what was there before was ok. Was nice to with minimal effort get at least unit tests up and running fairly quickly, and have PDK automatically align ruby version, etc. Ideally there'd be enough to optionally also add acceptance tests with minimal effort.

Having nothing for CI was a pretty big step backward in my opinion. I understand the desire not to support Gitlab CI because it isn't used by Puppet, but from a customer perspective it was frustrating to lose that. Now we have to fork the templates, develop a process to keep it updated with changes sourced from Puppet, and as well as maintain our portion of the templates.