Set up KDS commit tracking automation

[indirectlylit]

See https://design-system.learningequality.org/release-process/ for previous work.

I think the main next goals should be to ensure that:

1. Anyone can test the results of a PR to KDS in the development branches of Studio and Kolibri
2. The development branches of Studio and Kolibri stay up-to-date with the latest HEAD of KDS

It's not trivial to achieve these goals with github automation because there are many situations where there needs to be a human in the loop to vet changes, test for regressions, and add corresponding code in the other repo to account for breaking changes and new features in KDS.

Some examples of scenarios requiring iterative testing between repos:

• fix a bug in Studio or Kolibri
• migrate a feature from the other products to KDS
• deprecate functionality
• make a global change that needs testing in both products

Below is a possible automation strategy to try smoothing these processes.

At a high level, KDS PRs would use GitHub Actions to maintain associated feature branches and PRs targeting the development branches in both Studio and Kolibri. Within that feature branch, actions would keep the package.json and yarn.lock files updated to point at at the latest commit of the PR branch. This should allow CD pipelines to generate testable versions of the products, specifically cloud deployments of Studio and .pex files for Kolibri.

Step-by-step:

1. When a KDS PR is opened, our Github Action opens a new PR against both Studio and Kolibri development branches. A new feature branch is created in those repos with a name like kds-pr-[PR NUMBER] and an associated draft pull request with a name like Design System PR #[PR NUMBER]. These PRs use our existing CD and CI systems for testing and validation.
2. If desired, LE staff can push commits to the kds-pr-[PR NUMBER] branch and add info to the PR. Only the branch name needs to stay the same
3. As further changes are pushed to the KDS PR, our Github Action adds new commits to the other two PRs. These should update package.json and yarn.lock to point at the latest. We should be careful to handle force-push and other edge case situations. Also note that "kolibri core for export" needs to be updated.

It's somewhat important that the PRs in Studio and Kolibri don't get merged until the corresponding KDS PR is merged. If they do, the dependent projects will be left pointing at a commit on a feature branch in KDS rather than on the main branch.

Rather, the Kolibri and Studio PRs should stay in 'draft' until the KDS PR is merged, and if they're taken out of draft, our github actions could possibly provide a warning.

Once the KDS PR is merged, the Studio and Kolibri PRs would be updated to pin KDS to the merge commit of that KDS PR on main. At this point any final testing or edits in the products could occur and a final merge would be made to the develop branch.

Alternatively if the KDS PR is closed for some reason, the corresponding product PRs should probably also be closed.

[indirectlylit]

@sairina @nucleogenesis @rtibbles here is a possible github automation strategy that could help smooth the testing and updating friction between KDS and the other two key products, Studio and the Learning Platform.

I don't expect this is 100% correct or the final word on the matter, but based on our experiences over the last couple months I believe this could be a step in the right direction.

Good luck!

[MisRob]

Closing in favor of #532