fix(layers): release process + remove duplicate code

[dreamorosi]

Description of your changes

This PR tackles two separate but related issues: #1047 and #1053. All changes are related to the workflows that run as a result of a PR, a merge, or a release.

In an effort to try to minimise issues related to workflows this PR tries to remove duplicate code across workflows by creating a reusable and separate workflow around two flows:

• Running unit tests on all utils, examples, and layer-publisher
• Publishing docs (both main docs & API)

These generalised workflows can now be called by another workflow so that the amount of repeated code is reduced.

For example, before this change, the same code for running the unit tests was repeated in the workflows that run:

• On merge
• On a PR update
• On a release

Every time a change was needed or a new directory was added us maintainers had to go in each file and replicate the changes. This was needlessly time consuming and error prone, especially this last point is proved by the uptick of issues generated by the introduction of a new folder (layer-publisher).

With this change, the logic needed to run the tests has been extracted in a separate workflow that is now found at .github/workflows/reusable-run-unit-tests.yml. This workflow can be called by another workflow this way:

run-unit-tests:
    uses: ./.github/workflows/reusable-run-unit-tests.yml

This way, the three workflows mentioned above will have only these two lines, and any change required to the logic will happen in a single place.

The steps needed to publish the docs also followed a similar pattern. The logic was replicated across two workflows that run:

• On merge
• On a release

In this case, the steps had slight differences related to the fact that we want to publish the docs under two different paths based on the stage.

This PR creates a reusable workflow called .github/workflows/reusable-publish-docs.yml that accepts some inputs that will help the workflow to publish on the right path based on the values passed.

Note: this PR also sneaks in a minor wording change in the PR_TEMPLATE file that was causing some workflows that are in charge of labelling issues to fail.

How to verify this change

I have ran the various the workflows in a fork but please note that some of them fail at later stages because the token needed to publish to NPM is not present in the fork.

Example of "Make Release" workflow:

Example of "On PR Merge" workflow - when a PR is still open:

Example of "On PR Merge" workflow - when a PR is actually merged:

To see an example of the workflow that runs when a PR is updated, see the checks below.

Related issues, RFCs

Issue number: #1047
Issue number: #1053

PR status

Is this ready for review?: YES
Is it a breaking change?: NO

Checklist

• My changes meet the tenets criteria
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• My changes generate no new warnings
• The code coverage hasn't decreased
• The PR title follows the conventional commit semantics

Breaking change checklist

N/A

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[dreamorosi]

This line was interpreted by the workflow as an actual issue number. The workflow was then trying to assign a label to it but since it doesn't exist it would fail.

[flochaz]

Love it !

[ijemmy]

Please double check the value in inputs.workflow_origin

(Optional)
Would it be possible to put reusable workflows in a reusable directory?

It might also worth going through this in our maintainer sync so everyone is aware, how we structure them + naming convention.

[dreamorosi]

It might also worth going through this in our maintainer sync so everyone is aware, how we structure them + naming convention.

Yes, I'm still planning to document all this in written form #1038

[dreamorosi]

(Optional) Would it be possible to put reusable workflows in a reusable directory?

I'd need to test this (and I will), but according to the docs (sentence after first paragraph - doesn't have a /*) & this SO answer, GitHub expects the workflow to be only in the .github/workflows directory and subdirectories might not work.

[dreamorosi]

Merging this as Florian already approved the previous iteration and the only difference is a word in the repo name of a workflow

[dreamorosi]

@ijemmy I have tested your suggestion in a fork, by defining a dummy workflow at top level that calls another in a subfolder:

it throws this error when pushed preventing to start the workshop: