Heptapod 0.17.0rc1 released with 3 tech previews

Omnibus and Docker

While Heptapod 0.16.0 allowed us to have our own Omnibus build, and hence in particular to ship modified or new static assets (see heptapod#338), we were still building the final Docker image as a modification on top of that.

In the 0.17 cycle, we followed up on that initial effort, to the point where the final Docker image is the one generated by Omnibus. Since that image is essentially a preinstallation of the Debian pacakge generated by Omnibus for Ubuntu 16.04, this means in particular that

• we finally have a viable Omnibus Debian package for Ubuntu 16.04. This is the missing all-in-one installation option for those of you that would prefer not to use Docker yet won't go all the way to manage an installation from source, but it's hardly tested outside of the quite special Docker environment. That makes our first technology preview.

  We are currently looking at options for proper distribution of the Omnibus Debian package. Meanwhile, please contact us directly if you want to give it a try. Also don't hesitate to tell us if you're interested in other Linux distributions.

• the configuration of Heptapod specific services (hg-inner-http and hgitaly) can be managed like other GitLab services, with /etc/gitlab/gitlab.rb or Docker environment variables and gitlab-ctl reconfigure

• our final Docker image is smaller by almost 200MB (uncompressed).

• the whole process is much more automated. We're close to the point where pushing a tag in the main Heptapod repository (Rails application) would go all the way to produce the Omnibus package and Docker image and run the final functional tests on top of that. This gives us more time to focus on the development itself.

Version numbers policy for components

With Heptapod 0.17, we will be stopping to attribute the general version number to all our components, such as Heptapod Workhorse or py-heptapod. It was convenient for a while, allowing us to move forward without asking ourselves premature questions, but lately it had become mostly a drag.

This will save us lots of time, meaning we'll have more for features and bug fixes.

See heptapod#352 for full details of the new version policy.

Refinements on the HGitaly plan

We've had steady progress in the HGitaly project, which is the cornerstone of the native Mercurial mode, i.e., GitLab handling Mercurial repositories without any conversion to Git happening under the hood.

First, we've make the plan more concrete by laying down three milestones for integration of the Mercurial native mode. These are not tied to Heptapod version numbers, because we have to bump the minor version number (the "y" in "x.y") when there are significant changes, and some of these changes are tied to an external schedule, namely upstream GitLab releases.

HGitaly will be shipped for the first time with Heptapod 0.17 and unconditionally serve archive requests (heptapod#204). Since this is quite independent from the rest of the application, this will serve as a general warm-up.

User exposition of the Mercurial native mode

In the user experience, Mercurial native projects will be treated as if they were under different version control system: a new option beside Mercurial and Git at creation time, and explicit display on the Project home page etc.

If you want to try the native mode, you'll have to activate "Mercurial (native)" in the new Application setting for VCS types. Then users can create Mercurial native projects.

Of course, eventually, we'll only have one type of Mercurial project, and that will be the native one. But we still have a long way to go for that.

What is supposed to work in 0.17.0rc1

• push and pull should be the same as for regular Mercurial projects
• Mercurial commit hashes only, everywhere in the web application (UI and API). This is the main goal of the HGitaly1 milestone.
• basic project browsing, with some broken pages. For example, at the time of this writing, file lists ("trees") but commit and file ("blobs") views are still broken.
• the inner mechanism that notifies the main application of Mercurial changes has not been adapted yet. Therefore, do not expect Merge Request detection and pipeline creation to work. We have a clear plan (heptapod#364) for that, and expect it to be ready for the final 0.17.0 release.

How to report broken pages or requests

First, thanks for wanting to give us feedback on this experimental mode. Too much issue duplication would be counter productive, so here's what you can do about that.

The majority of problems are expected to be missing HGitaly method implementations. They come with explicit logs in the Rails application:

Gitlab::Git::CommandError (12:Not implemented. Tracking issue: https://foss.heptapod.net/heptapod/hgitaly/-/issues/15.):
  lib/gitlab/git/wraps_gitaly_errors.rb:13:in `rescue in wrapped_gitaly_errors'
  (...)

and in the Mercurial log:

[2020-11-09 11:11:58 +0100] [793335] [ERROR] [hgitaly.errors] Not implemented. Tracking issue: https://foss.heptapod.net/heptapod/hgitaly/-/issues/15

You can then add the use case you've stumbled over to the tracking issue if needed, and upvote it if you feel it to be more important that other similar issues.

What will still be missing in the final 0.17.0

• Migration scripts for existing (hg-git based) projects
• We will still be using an auxiliary Git repository to present some content. Removing this need will be the goal of the Hgitaly2 milestone.
• Potentially everything that's not working in rc1 and we didn't had time to fix before the final release.