Heptapod 0.24.0rc1 released, moving to GitLab 14

Published:
By Georges Racinet

We're glad to announce the release of Heptapod 0.24.0rc1, the first to feature GitLab 14. It should be followed in a few days by the final 0.24.0 version.

As all major GitLab version changes, this is a pivotal version for upgrading existing instances. Please read below if you wish to upgrade from Heptapod <0.23 or to Heptapod ≥0.25.

The release candidate was installed on August 24th on foss.heptapod.net. The final version will be installed simultaneously on foss.heptapod.net and heptapod.host.

Heptapod 0.24.0 will also be followed shortly by 0.25.0rc1, featuring GitLab 14.1 and more features.

Heptapod 0.24.0rc1 can be installed as a Docker image and from source.

The full changelog is available as usual alongside the sources.

Migrating existing instances

As very clearly stated in upstream recommendations, to upgrade an existing instance to GitLab 14.0, one must first upgrade to 13.12, give some time for background migrations to finish, and only then upgrade to 14.0. The third number (patch) is not very relevant to this matter, but it is a good practice to select the latest available one each time, as it can correct some bugs in migrations.

If one wishes to proceed to later versions in the GitLab 14 series, such as 14.1 or 14.2, one must stop at 13.12 and 14.0 before proceeding further, and wait for completion of background migrations after each stop.

In terms of Heptapod versions, this translates to:

  • upgrade to Heptapod 0.23 (GitLab 13.12), wait for background migrations to complete
  • upgrade to Heptapod 0.24 (GitLab 14.0)
  • if you wish to upgrade further to Heptapod ≥0.25 (GitLab ≥14.1), upgrade to 0.24 first, wait again for background migrations to complete and you're then free to jump to any Heptapod version that relies on GitLab 14.

Note

Checking the status of background migrations can be done in the Admin area from Heptapod 0.24 (GitLab 14.0) onwards.

In earlier versions, from Heptapod 0.14 (GitLab 12.10) onwards, this has to be done with the command-line.

  • For Omnibus/Docker installations, as root:

    gitlab-rails runner -e production 'puts Gitlab::BackgroundMigration.remaining'

  • For source installations, as the proper system user and from the Rails application directory:

    bundle exec rails runner -e production 'puts Gitlab::BackgroundMigration.remaining'

Heptapod 0.25 and native Mercurial projects

In an unusual move, we actually prepared the upstream version change to GitLab 14.0 and GitLab 14.1 at the same time. The latter will naturally become Heptapod 0.25 and will provide more important changes in Heptapod specifics.

Notably, we plan to make "native" Mercurial the norm for new projects in Heptapod 0.25. This will involve an automatic reconfiguration of the allowed and default VCS types settings of all instances, both at the global and group levels.

More background about native and non-native projects can be found in our previous article The road to fully native Mercurial in Heptapod. At this point, after many months of using native projects in production, we feel that creating non-native Mercurial projects today only offers drawbacks for users.

Nevertheless, we will let Administrators reactivate the non-native Mercurial VCS type, and should not touch these settings again until we drop support for non-native projects completely, which still lies in some unforeseenable, and in any case much further, future.

The tracking issue for this move is heptapod#523.