High level overview

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.

Workflows and events

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_dispatch event 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.

Composite actions

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.

Env constants

One more composite action that is absent on the diagram but should be called at the beginning of each job is the one that:

1. Calls actions/checkout to check out the repo.
2. Exports env variables from constants.env file to the job runner context.

To be continued

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.