In this part we will observe the high level architecture of the solution: the proposed workflows and the order in that they are called. We will also find duplicated steps and extract them to the composite actions.
Let's take a look at the vertical Ghant diagram of the pipeline triggered by pushing a tag.
- The main publish-release-on-tag workflow is triggered when a user pushes a tag.
- It triggers build-assets-on-release implicitly by creating a release.
- The main workflow also explicitly triggers (emitting
workflow_dispatch) event 2 other workflows responsible for publishing an extension on different stores.
Important thing here is that all of these workflows can be triggered by user directly, without triggering the main workflow. Because of that I have added additional checks to them:
- build-assets-on-release is triggered when a user publishes a new release (it can not have a zip asset).
publish-on-chrome-webstore and publish-on-firefox-addons can be triggered manually using
workflow_dispatchevent on any branch or tag that don't have a release.
Apart from this, we are going to create one more workflow that will build and test an extension on pushes to branches and on Pull Requests creation:
Separating the whole pipeline into workflows:
- Prevents us from creating a monster workflow file.
- Avoids code duplication
- Allows the separated workflows to be triggered, cancelled or repeated independently and executed in parallel.
In terms of code duplication, we can do better. Look at the steps marked in green and to the duplicated grey block of the "publishing" workflows. We are going to extract them to the Composite Actions that will be placed locally in the same repository:
From the workflows's point of view they are usual actions that use a runner's filesystem and a workflow context. You can also notice that one composite action can use another composite action as its step.
One more composite action that is absent on the diagram but should be called at the beginning of each job is the one that:
actions/checkoutto check out the repo.
- Exports env variables from
constants.envfile to the job runner context.
In the following parts we will follow the "bottom-up" approach and will implement workflows and composite actions shown on the diagram one by one.