Limit maintenance in the push-content.yml workflow of documentation content repositories

Current problem

This applies to repositories related to documentation components with several versions (bcd, bonita, test-toolkit) i.e not with a single branch (cloud, labs).

Today, we hard code the version in the event we sent. When initializing the content for a new version, the version must be updated in the event and sometimes it is not by mistake. This means that the event are sent with wrong information and the Netlify logs are not accurate. As we almost never check the workflow and the logs, it can take weeks before we detect the problem, and often, we discover it when we review the Netlify logs to troubleshoot an issue. This is too late and this can leads to wrong conclusions.

The push-content event is sent when a new push is done in the branch The allowed branch for the push event triggering the workflow is hard coded in the workflow. It must match the actual branch where the workflow is stored. If the branch value in the workflow doesn't match the actual branch, the workflow doesn't run and the event is not sent.

Proposal

My proposal is that instead of hard coded the version in the event, we could deduced it from the branch that stores the definition of the workflow. This will work with both push and workflow_dispatch events. The information is available in the github context. On new component version initialization, the event will be correct, but the allowed branch of the push event may be inaccurate. The event won't be sent until it is updated. At a given time, someone will notice that when they merge their PR in this branch, the change is not pushed to production.

We could store the whole logic in a shared action or in a reusable workflow as we plan to do for other workflows in #422. It will help updating all repositories and implement new features in the future like #228 and #275.

Using a shared actions let provide more details about the sources. The GitHub context lets retrieve information about the repository. This could be used to validate that the branch and the repository are part of the production site. We have the information in the doc-site repo in the Antora playbook and in the preview script (for the mapping between the component name and the repo url). This validation would prevent to push to production when we receive an event from a repo that is not part of the production site (extra publish).

The information about the component and its version are defined in the antora.yml file. They could be retrieve from this file as well.

Current workflow configurations

Bonita 2021.1

https://github.com/bonitasoft/bonita-doc/blob/9f6cb8779e3e270bbd5aa1849c773033447772f2/.github/workflows/push-content.yml#L3-L22

Bonita 2023.1

https://github.com/bonitasoft/bonita-doc/blob/8d06f2cab16e8efa67a47e3869122fde633ba73d/.github/workflows/push-content.yml#L3-L22

bonitasoft / bonita-documentation-site