|
| 1 | +# GitHub Workflows |
| 2 | + |
| 3 | +# Syncing LTS Branches |
| 4 | + |
| 5 | +Solo-Apis is a public, read-only mirror for API definitions. In order to keep API definitions in sync, we automate the process of syncing long term support (LTS) branches. |
| 6 | + |
| 7 | +To keep the LTS branches unique, we prefix them with the name of the owner repo. For example, in gloo-edge the `1.8.x` LTS branch is tracked by the `gloo-1.8.x` LTS branch in solo-apis. |
| 8 | + |
| 9 | +#### How do Gloo Edge APIs get synced? |
| 10 | + |
| 11 | +1. A Gloo release occurs (ie v1.8.1 is released from LTS branch v1.8.x) |
| 12 | +1. A Gloo GHA generates the new APIs and pushes those to a branch (ie sync-apis/gloo-v1.8.x/gloo-v1.8.1) |
| 13 | +1. A [Solo-Apis GHA](#create-pr-for-lts-branch) notices that a commit was pushed to a `sync-apis` prefixed branch, and creates a PR. |
| 14 | +1. That PR is manually reviewed by a developer, and eventually approved |
| 15 | +1. A [Solo-Apis GHA](#tag-commit-on-lts-branch) notices that a commit is pushed to a LTS branch (ie gloo-v1.8.x) and tags the commit. This tag is referenced by other repositories. |
| 16 | + |
| 17 | +The GitHub actions that enable this process are defined below: |
| 18 | + |
| 19 | +## Create PR for LTS Branch |
| 20 | + |
| 21 | +The repo that owns API definitions is responsible for deciding when to update API definitions (ie after a release) and pushing the new API to a branch in solo-apis. |
| 22 | + |
| 23 | +This action only needs to know 2 pieces of information: |
| 24 | +1. The name of the LTS branch it should merge the code into |
| 25 | +1. The tag that should be applied to the merge commit |
| 26 | + |
| 27 | +We decided to use the branch name to pass this information. The workflow only operates on branches in the following format: |
| 28 | +```sync-apis/{LTS_BRANCH_NAME}/{LTS_TAG_NAME}``` |
| 29 | + |
| 30 | +This allows the workflow to operate successfully, knowing the least information possible about the source repo that triggered the sync. |
| 31 | + |
| 32 | +The workflow has 2 responsibilities: |
| 33 | +1. To open a pull request to the LTS branch name |
| 34 | +1. To signify the tag that should be applied, when the PR merges |
| 35 | + |
| 36 | +The first step is easy, since the LTS branch is extracted from the branch name. |
| 37 | +The second step is more challenging since after the PR merges, the GitHub event that is triggered does not contain a reference to the name of the branch that merged. Therefore, we don't have a way to determine the name of the tag to apply. **We use a little trick to resolve this: providing a commit message with the tag included, and then extracting that commit message when generating a tag name.** |
| 38 | + |
| 39 | + |
| 40 | +*Note: This workflow opens a PR, but expects manual intervention by an engineer to approve the PR* |
| 41 | + |
| 42 | +## Tag Commit on LTS Branch |
| 43 | + |
| 44 | +After PRs are merged into LTS branches, we: |
| 45 | +1. Extract the latest commit message (which the above workflow provided) |
| 46 | +1. Determine the tag name from the commit message |
| 47 | +1. Push a tag name for that commit |
0 commit comments