If you have team members who shouldn't have access to GitHub but work depending on it, notification integration is the best thing you can add.
Also this article will be useful for those who want to automate the reporting of actions performed on GitHub. Or want to learn how to use the output for reusable workflows.
It doesn't matter what cloud you are using. In this method, we can still run the workflow itself or call it from another workflow.
Step 1 - Configure reusable workflows
Firstly, let’s add reusable (called) workflows.
- Create files:
2. Now let's configure the workflows to make them reusable from root:
aks_ci, web_app_docker_ci_1, web_app_docker_ci_2 will have the same configurations to send job status codes and to be called by other workflows. Therefore, you can write them similarly.
From the CI we need multi jobs (build and deploy).
All of these workflows must have workflow_call and outputs:
Keep in mind that workflow_call has nothing to do with workflow_dispatch. They are completely different configurations.
In the workflow_call configuration, we will declare that we will output variables named 'build_status' and 'deploy_status' and where to get them from.
3. Then we need to get output itself from the build step:
We cannot fail to mention that the 'Build Step Status' should be after the build steps (between lines 46 and 48).
Note that we are using our step identifiers here. Using this identifier, we can identify specifically this output.
The same for a deployment job.
Deployment code must be between line 79 and 81.
4. cypress_test_ci can be like any workflow that does not require getting the status of each job. This means that we can get the status of the workflow as a whole.
Step 2 - Configure root workflow
Finally, we can add root workflow.
- Create a root_ci file:
2. Add calls to this workflow to utilize the reusable configurations we've made.
Step 3 - Configurations for any types of notifications
Once we have added reusable and root workflows, state output variables for multi-tasking, we can start using it.
Let’s add notification job to root workflow: (start with line 28)
Here we have added configuration to run in any case, even if previous jobs completed successfully or completed with errors. Notifications will be used when all jobs are completed with any status.
Notifications can generally be divided into 4 parts:
- Successful finished
- Build failed – Workflow failed completely
- Deploy failed – The build was successful, but deployment failed
- Test finished successfully.
Successful finished
If deployments and tests are finished successfully, notification will be successful.
Workflow failed completely
If the build is completed unsuccessfully, the notification will fail.
The build was successful, but deployment failed
If the deploy is completed unsuccessfully, the notification will fail.
Test finished successfully, but build and deployment failed
If the build and deployment failed, but testing was successful, a notification will appear indicating a successful test with an unsuccessful deployment.
Conclusion
Reusable workflows and notification systems are a really flexible and powerful addition to automation that can help your team accelerate CI/CD and simplify progress tracking.
References
- Calling reusable workflows - [https://docs.github.com/ru/actions/sharing-automations/reusing-workflows#calling-a-reusable-workflow]
- Creating reusable workflows - [https://docs.github.com/ru/actions/sharing-automations/reusing-workflows#creating-a-reusable-workflow]
- Outputs - [https://docs.github.com/ru/actions/writing-workflows/choosing-what-your-workflow-does/passing-information-between-jobs#example-defining-outputs-for-a-job]
- Conditionals - [https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/using-conditions-to-control-job-execution]
Dependences - [https://docs.github.com/ru/actions/writing-workflows/workflow-syntax-for-github-actions#example-requiring-successful-dependent-jobs]
Denis Tuzhilin | DevOps & Solution Architecture | CI/CD | GitHub actions
