This article is about workflows, especially related to GitHub Actions. A workflow does a wide variety of tasks for a project, from simple linting to deployment. The more projects you create now, the more often you reuse exactly such workflows. GitHub allows you to refer to other workflow configurations, so the logic can be written once then reused.

• By using them, we automatically write less duplicated code, which would otherwise be copied from project to project.
• This also results in easier maintenance of the workflows, because only one central repository has to be touched to propagate the changes. This also makes security-related changes or new features directly accessible to all projects.
• We have also found that using the workflows is simplified by being able to specify default values. This means that you don’t have to specify all the values for the workflow, but only the ones you want to change.
• Another benefit is that a reusable workflow can be created easily and quickly, making the barrier to use very low. So, on the whole, we can say that the central repository contains mainly tested and efficient workflows that can be easily used.

However, during the development we also noticed some disadvantages. The known disadvantages are:

• For example, it is currently not possible to access environment variables in the reusable workflow. They must be passed directly as input.
• The problem also affects secrets, which can only be passed explicitly as secrets, but cannot be taken as simple inputs.

Overall, Staffbase decided to use reusable workflows because the advantages outweigh the disadvantages.

This section will briefly describe how a reusable workflow can be used and what to look out for. The collection of reusable workflows offers different example configurations. The usage will be explained using the AutoDev workflow, which merges changes from PRs to a new branch with the current state of the main branch.

The first step is to read the documentation. Thereby it can be seen which parameters are optional and which default values have been assigned. Following this, the configuration can be copied and pasted into the corresponding project. Afterwards only the parameters have to be adjusted, so that it fits the respective project. The parameter base specifies the main branch, which provides the code base. The changes of the PRs are merged into the branch defined with the parameter branch. To activate the workflow on a PR, a label must be set, which is defined with the label parameter. Due to the fact that conflicts can arise between PRs, there is the possibility to get feedback from the workflow after a successful merge. For this, there are the parameters labels and comments to get either a status as another label or a new comment at the PR. Finally, the data of the user who should commit to the new branch can be specified with user and email. Additionally, it is necessary to pass a secret token so that all branches of the project can be fetched.

The following graphic shows an example configuration with a reusable workflow and one with explicit use of the AutoDev action. The comparison should once again show the differences and advantages. It can be seen that you save a few lines of code, can ensure consistent use of the action across projects, and changes are easier to make.

Reusable Workflows offer a strong potential to simplify the work with workflows and make it more maintainable. This helps to avoid consequential errors and to take a better look at security in all projects with regard to workflows. However, there are currently still some disadvantages to be aware of, as they require more manual work.

If you want to learn more about reusable workflows, you can take a look at our summary of workflows and for more detailed information. You can take a look at the GitHub documentation.