powertools-lambda-typescript

powertools-lambda-typescript copied to clipboard

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

• [x] My changes meet the tenets criteria
• [x] I have performed a self-review of my own code
• [x] I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• [x] My changes generate no new warnings
• [x] The code coverage hasn't decreased
• [x] 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.