Establish the new and automated release process

[MisRob]

Kolibri-Studio-KDS workflow

• KDS releases will be installed to
  • Kolibri's develop and release-v*
  • Studio's unstable
• Working branches targeting develop/release-v*/unstable can reference an unreleased KDS commit (typically new KDS work in support of the Kolibri/Studio feature being developed), but it is not allowed to merge a working branch into them as long as it references an unreleased KDS commit. Example:
  • (1) A developer works on refactoring card components in Kolibri on a working branch from develop
  • (2) They need to make some new updates to KDS card component, so they open a KDS pull request. It is reviewed and merged.
  • (3) In their Kolibri working branch, they reference the latest KDS commit directly.
  • (4) KDS release manager prepares a new KDS release that contains the change
  • (5) This KDS release is installed into develop
  • (6) The developer rebases their working branch on top of the latest develop before merging their PR and can therefore remove their direct KDS commit reference

Automation

To be able to support the workflow above efficiently, we will need to release KDS frequently (perhaps bi-weekly or even weekly, to be determined) and be always ready to release upon request so that it doesn't block merging PRs in the products. This will be supported by the automated releases utilizing npm and dependabot. The automated KDS release part of the workflow above will work in the following way:

• (1) After a new KDS version is tagged, it will be automatically published to npm

  • We can re-use https://github.com/learningequality/le-utils/blob/main/.github/workflows/npm-publish.yml

• (2) dependabot will open PRs with the new KDS version installed

  • PRs are opened to Kolibri's default branch (develop or release-v*), and Studio's unstable
  • PRs are then treated as for any other dependency - we test and merge them, or push some updates if needed

Tasks

Preview Give feedback

1. Automate publishing KDS to npm triggered by tagging a new KDS version
2. Present the new workflow to the team
3. Set up reminders for developers to inform KDS release manager when they have/need some new KDS work (on Slack, during regular meetings)
4. Update the internal release documentation