galoymoney / meta-release Goto Github PK

• features should also bump minor not just breaking (https://github.com/GaloyMoney/meta-release/blob/main/ci/tasks/bump-version.sh#L10)

• Lets use a tool for this: https://github.com/GaloyMoney/meta-release/blob/main/ci/tasks/bump-version.sh#L13
  Options:
  https://github.com/usvc/semver
  https://github.com/c4urself/bump2version/#installation
  (...) probably more - just did a brief search
  requirements: - sem ver compatible; nice to have: - can bump version in arbitrary files (for when we release helm or node stuff we want to update the version in the meta data files)

• use a separate resource for this (https://github.com/GaloyMoney/meta-release/blob/main/ci/pipeline.yml#L86) like infra-repo-stable. put the branch in the resource definition.

• don't use a script for this (https://github.com/GaloyMoney/meta-release/blob/main/ci/pipeline.yml#L92) there is a concourse resource https://github.com/concourse/github-release-resource
  you can see how to use it here https://github.com/bodymindarts/cepler/blob/main/ci/pipeline.yml#L283-L304

The changelog generation needs to be refactored following the structure changes due to the migration of some apps in to the monorepo. Links to the source repo commits/PRs also need to be fixed.

Primary desired outcome is
a)

• document known good combination of releases for our entire stack (includes mobile)
  -> versioned mobile release
  • include automated release notes generation
  • GitHub release
    -> pin the release together with the versioned backend stack

b)

• release process is automated end-to-end and reproducible without specific knowledge

Secondary task
a)

• evaluate pain points of mobile app releasing
  -> consider best long term releasing strategy (given needs of ^^^)
  -> conclude to redesign parts / all / none of the existing setup
  b)
• develop boilerplate / scaffolding to hook in e2e tests (probably against staging)

Current pain points:

• custom knowledge required
• hard part is not creating the APK -> managing the phased roll out

Open Questions:
separate versions for android, iOS, Huawai?

Can release description be tied to conventional commits?
-> probably simply generic description

Leverage fast lane

Additional thoughts:
OS builds are free <- biggest reason not to migrate to concourse
Ideally we decouple the scripting from circle ci (so we could move around)