Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • heptapod heptapod
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 198
    • Issues 198
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • heptapodheptapod
  • heptapodheptapod
  • Issues
  • #496
Closed
Open
Issue created Jun 11, 2021 by Georges Racinet@gracinet🦑Owner28 of 28 checklist items completed28/28 checklist items

Branches shift: Heptapod 0.21 becomes oldstable

Description

The ultimate goal is to open up the Heptapod 0.23 (GitLab 13.12) development cycle.

  • Bumped series: oldstable
  • Shifted series: stable

Merging

Most tasks The goal is to merge the shifted branch into the bumped branch.

Unless explicitely stated, the branch names coincide with the series name as defined above, hence for example a simple merge/commit with the bumped series being oldstable (and the shifted series being stable) would be done with:

hg update oldstable
hg merge stable
hg commit

CI Images

  • heptapod-base
    • merge, check/fix assets/install_pythonlibs
    • commit, push
    • pipeline ok
  • heptapod-gitaly
    • merge, commit, push
    • pipeline ok
  • mercurial/hg-current
    • merge, check Mercurial version as expected in kaniko.sh for HG_VERSION==current.
    • merge, commit, push
    • pipeline ok (check resulting Mercurial version)

Components that are forked from upstream GitLab

For these ones, the mapping from series to branch names is:

default: heptapod
stable: heptapod-stable
oldstable: heptapod-oldstable
  • Heptapod Shell
    • merge, commit, push
    • pipeline ok
  • Heptapod Rails:
    • merge, don't commit
    • Important check general base image in heptapod-ci.yml, it should match the bumped series. Release scripts will read this to know for which series they are working. A wrong value hear gives rise to wildly inconsistent binary builds (Omnibus etc.).
    • check cache keys in heptapod-ci.yml. Should be consistent with the relevant Heptapod and GitLab versions in the bumped branch

Python components

  • py-heptapod
    • merge, commit, push
    • pipeline ok (check it's been running on the expected "current" Mercurial version for the bumped branch)
  • HGitaly
    • merge, check that the heptapod-gitaly image is as expected for the bumped branch in .gitlab-ci.yml
    • commit, push
    • pipeline ok

Development, build and release tooling

  • heptapod-tests:
    • merge and check the base image name in .gitlab-ci.yml: it should be the target Heptapod version, e.g, 0-21-testing.
    • push and watch the pipeline use the appropriate image.
  • HDK: update the release-stable or release-oldstable entry in lib/gdk/config.rb on the heptapod branch (we have one single branch to rule all series as of this writing but that can change in face of big future structural changes).
  • Heptapod Rails:
    • merge the bumped branch into the release branch (e.g., 'heptapod-0-21', 'heptapod-0-22' etc). The diff should be almost empty, especially if the shifted branch was fully merged in the release branch.
    • commit/push (skip CI if really empty)
  • Omnibus Heptapod (branch naming is like all forks, heptapod, heptapod-stable etc.) merge the shifted branch into the bumped branch, commit, push
  • Validate release process: in Heptapod Rails pipelines
    • trigger the tarball job related to previous push on the release branch.
    • in the job log, check that target Omnibus branch for automatic release is the bumped branch of Omnibus, take note of changeset node ID (part of tarball name) and SHA256 of the tarball.
    • In Omnibus Heptapod, create a topic on the bumped branch with
      • HEPTAPOD_VERSION: x.y-NODE where NODE is the node ID just noted (past example 0.21-a99e86a76ee462e720bcb80c7feb080f06bb9b7d)
      • HEPTAPOD_RAILS_SHA256: the SHA256 of the tarball
    • push that, create MR, and wait for pipeline to
      • create the proper x-y-testing image
      • trigger passing heptapod-tests pipeline on the created image (by its hash tag)
Edited Jun 11, 2021 by Georges Racinet
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking