Introduce Code Documentation Workflow Dependent on CMake Workflow #68
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR separates workflows by task such that they become reusable [7], e.g., the
cmake
workflow which content is required and duplicated in the other workflows will run in the end only once. This will save computational power and time in the end. There are different events that may trigger workflows given in [6]. Another option is to call the workflows in the main workflow directly [8]. For the two former options there is a big difference in reusability of the dependent workflows. It is worth testing the context reusability of both versions (see below).Advantage:
Unfortunately the dependent workflows do not inherent the whole environment. As such we need to make sure to maintain the build directory and the installations for the upcoming workflows. There are two approaches given by GitHub, (1) Caching, and (2) Artifacts. A docker solution is also given in [8].
Caching makes more sense in our case as we need the result directly and only for the workflows that depend on a particular workflow, i.e., the
build
directory is not a long living artifact, but a short term object only required for the dependent workflows [4]. The caching approach is also less time consuming and thus, preferable.In total, we add and modify the following files to have the resulting dependency graph:
modified:
.github/workflows/cmake-multi-platform.yml
new file:
.github/workflows/code-documentation.yml
[1] https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows
[2] https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts
[3] https://docs.github.com/en/organizations/managing-organization-settings/configuring-the-retention-period-for-github-actions-artifacts-and-logs-in-your-organization
[4] https://levelup.gitconnected.com/github-actions-how-to-share-data-between-jobs-fc1547defc3e
[5] https://stackoverflow.com/questions/58457140/dependencies-between-workflows-on-github-actions
[6] https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run
[7] https://docs.github.com/en/actions/using-workflows/reusing-workflows
[8] https://stackoverflow.com/questions/57498605/github-actions-share-workspace-artifacts-between-jobs