Rename beaker.yml?

[bastelfreak]

The job does more than only beaker tests, should the filename reflect that?

[ekohl]

My reasoning was:

• basic - just unit testing
• beaker - acceptance testing using beaker
• litmus (future) - acceptance testing using litmus

Any other thoughts on what would be clearer?

[logicminds]

I think to make more composable workflows they should be broken out into individual files.

1. validation, validation-ruby, validation-pdk
2. unit, unit-ruby, unit-pdk
3. acceptance
4. acceptance-litmus
5. acceptance-beaker

Then have an input to chose with acceptance framework to use when calling acceptance.

Take it a step further and separate out ruby based and pdk based. Allow user to chose pdk or ruby.

I don't know if this is how github actions work and if this is possible. From a software design perspecitive this would be called the adapter or provider pattern.

[ekohl]

Technically speaking you only refer to a filename of the workflow for an action. There are some limitations, like you can't call a workflow inside a matrix, it must happen on the top level of your (real) action and the reusable worfklow must be in .github/workflows for some reason; they can't be in the root directory of the git repo.

You also point to a git reference. We currently have a v1 branch and a 1.0.0 tag (by now we probably should tag 1.1.0) but such a change implies a v2 branch, which is perfectly OK. I always imagined we'd have to do that soon to accommodate non-VoxPupuli workflows since I couldn't plan ahead for those.

We also reuse some steps. For example, in our setup step we determine the test matrix based on metadata.json. This then is used in the unit and acceptance tests. We also have a dummy step that serves as a marker for a completely finished run, which allows you to set up branch protections easily (enabled GitHub's auto merging feature). Separating those out may make it much harder to consume.

But to be clear, I'm not opposed to splitting; just that we should continue to provide the complete workflow. Having a minimal action inside the module's repository is the key feature I was after (to minimize modulesyncs).

So we would then have:

• Type (full workflow, partial)
• Method (Ruby/Bundler, PDK)
• Individual name (basic, acceptance-$flavor)

So a filename may become flow-bundler-basic.yml, flow-pdk-acceptance-litmus.yml or partial-bundler-validation.yml.

And to state it explicitly: I've worked hard to make sure README describes how to use it. This crucial IMHO.

If we do agree on steps forward, I'd propose we:

• Start a v2-pre branch
• Update the README with the new convention, state it's work in progress and subject to change
• Rename existing workflows to suit
• See how things work out
• Once we're stable, rename branch to v2
• Change the default branch

Would this make sense?

[ekohl]

So we did start a v2, but didn't make it default yet. Perhaps we should have named it v2-pre.