# Shared workflows
###### tags: `Design`
| Author | Period | State |
| -------- | -------- | -------- |
| Dmitri Pal<br>Roman Volosatovs | December, 2022 | **🔴 Draft** |

## Overview

Current document defines the agreed to conventions related to the introduction and implementation of the shared (reusable) workflows in Enarx and Profian organizations.

## Conventions

* Shared workflows will be implemented in Enarx organization and will be reused by Profianinc organization.
* Shared workflows in the Enarx organization will be placed into ***.github*** repository.
* In the ***.github*** repository the ***.yml*** files that contain shared workflows will have the names as the ***.yml*** files in other repositories that would use/call/invoke the shared workflows. For example:
* If we decide to also have the invoking workflows apply to the ***.github*** repository and if we want to follow the naming convention, we will face a problem of shared and invoking workflows having the same file name in the ***.github*** repository. From the GitHub documentation Combining the two in the single file might not be supported. The documentation talks about the shared workflows as specific files. All examples of the shared workflows also contain only the shared workflows itself. Attempting to specify multiple `on` triggers will create testing complexity with questionable outcome. To avoid such complexity we will either:
* create a directory under the ***"workflows"*** directory in ***.github*** repo called ***"local"*** and place the calling workflows there - this is a preferred option that should work based on the documentation but have not been tested at the moment of writing.
* ***nix-update.yml*** in ***.github*** repo will contain the shared workflow .
* ***nix-update.yml*** in any other repo will contain invokation of the shared workflow.
* add files the to the main workflows directory with a ***"-local"*** suffix (this is a fallback option if the other option above does not work).
* We will add shared workflows gradually.
* We started with ***nix-update.yml***
* The next one will be ***automerge***
* Others will follow
The general flow of the introduction of the shared workflows will be:
* Create a PR for ***.github*** repo implementing the shared workflow
* Once reviewed and accepted create the PRs for other repositories to call the shared workflow.
* For now we have some scripts to do that. In future we might create a bot to do it.
* Wait for the most of the PRs to be merged before starting to work on the new shared workflow. Always check with the team whether it is OK to move forward with the next shared workflow and determine which repositories it should be implemented in.