Heptapodhttps://heptapod.net/2024-01-31T00:00:00+01:00HeptapodHeptapod 1.0 and a roadmap for 20242024-01-31T00:00:00+01:002024-01-31T00:00:00+01:00Georges Racinettag:heptapod.net,2024-01-31:/heptapod-1-0-2024-roadmap.html<p>With the release yesterday of Heptapod 1.0.0rc1, the close future of
Heptapod development has become clearer.</p>
<p>The release candidate was installed on <a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a>. The final
version is due next week.</p>
<p>Read this to know more about what we will be up to in the first half …</p><p>With the release yesterday of Heptapod 1.0.0rc1, the close future of
Heptapod development has become clearer.</p>
<p>The release candidate was installed on <a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a>. The final
version is due next week.</p>
<p>Read this to know more about what we will be up to in the first half
of the year.</p>
<div class="section" id="closing-the-gap-with-gitlab-upstream">
<h2>Closing the gap with GitLab upstream</h2>
<p>Long ago, we set ourselves two requirements for Heptapod 1.0:</p>
<ul class="simple">
<li>Stop depending on internal Git conversions of Mercurial:
This was reached with <a class="reference external" href="/heptapod-0.40.html">Heptapod 0.40</a>.</li>
<li>Be based on a supported GitLab version. This is brought by today's
release.</li>
</ul>
<p>In the past year, we've been improving our semi-automated process to
convert and merge upstream GitLab commits, and gradually catching up.</p>
<p>Early last autumn, the upstream merge started running unattended,
requiring human intervention only when needed. At this point it was
worth making a big effort to land on a supported upstream version as
soon as possible. This is where we stand now, with Heptapod 1.0
being based on GitLab 16.6.</p>
<p>Really closing the gap will require more work, and will still be the
absolute priority of Heptapod development in the forthcoming months,
with the goal of releasing Heptapod in the few
days following the corresponding GitLab release.</p>
<p>At this point, our users should expect a monthly release
pace. Meanwhile, we will still have to release faster than that.</p>
<p>We hope to release Heptapod 1.1 in the third week of February, at
about the same time of upstream dropping support for GitLab 16.6. It
will be based on GitLab 16.7, which is also a <a class="reference external" href="/pages/upgrade.html">landmark version</a>
for data migrations.</p>
<p>In Heptapod 1.2, we will probably jump again, as far as
GitLab 16.10 if possible.</p>
</div>
<div class="section" id="new-versioning-policy">
<h2>New versioning policy</h2>
<p>Starting with GitLab 17.0 (May 16th), we are considering aligning
Heptapod minor version numbers (x.y) with GitLab's. This would make
sense now that we are leaving the 0.something realm.</p>
<p>We hope this would bring us more clarity, both in development tools
and to our users.</p>
<p>So, instead of Heptapod 1.3 or 1.4, we could have 2.0 and keep
thereafter a policy that Heptapod x.y is based on GitLab (x+15).y, or
even simply Heptapod 17.0 and then Heptapod x.y will always be based
on GitLab x.y.</p>
<p>Don't hesitate to tell us what you think about it!</p>
<p>The third number (patch) for bug fixes and security releases will
obviously have to stay independent.</p>
</div>
<div class="section" id="towards-cloud-native-heptapod">
<h2>Towards Cloud Native Heptapod</h2>
<p>The other major work in progress is the transfer to HGitaly of all
operations on Mercurial repositories. This is also known as the <a class="reference external" href="https://foss.heptapod.net/groups/heptapod/-/milestones/45">HGitaly3</a>
milestone.</p>
<p>For historical perspective, the Heptapod project started a few months
before GitLab introduced the Gitaly component to encapsulate all
interactions with the Git repositories.</p>
<p>The goal of the Gitaly project was to
stop requiring the repositories to be present on the file system of
the web application (Rails), thus allowing independent horizontal
scaling, sharding, easier upgrades without downtime, etc. A good
analogy would be to say that Gitaly allows to treat Git repositories
as a specialized database.</p>
<p>This brought <a class="reference external" href="https://about.gitlab.com/topics/cloud-native/">Cloud Native</a> GitLab (CNG): a distribution of GitLab as
a set of containers, easy to deploy and manage, typically in a
Kubernetes cluster.</p>
<p>In the development of HGitaly, our counterpart of Gitaly for Mercurial,
we've been focusing first on the read-only side of the question.
It was indeed what we needed to get rid of the internal conversion to
auxiliary Git repositories. This was explained in
<a class="reference external" href="/the-road-to-fully-native-mercurial-in-heptapod.html#the-road-to-fully-native-mercurial-in-heptapod">The road to fully native Mercurial in Heptapod</a>.</p>
<p>The auxiliary Git conversion has always been a reading helper, so we
didn't have to change the existing write operations, which continued
to work pretty much as back in the days of Heptapod 0.12, by spawning
local <tt class="docutils literal">hg</tt> processes. At some point we simply decided that any new
operation should be done by HGitaly, to stop the increase of technical
debt.</p>
<p>Having HGitaly take charge of all write operations originating from
the web application is thus an important
gap to close in order to make a cloud-native Heptapod. The other one
would be to have HGitaly receive user pushes.</p>
<p>The <a class="reference external" href="/heptapod-0.40.html">Heptapod 0.40</a> release left us free to
turn ourselves to this question. We hope to reach the point where
HGitaly can be deployed in a separate system also by mid-2024.</p>
<p>For instance, in Heptapod 0.41, the fast-forward
Merge Request merge method is handled by HGitaly and Heptapod 1.0
generalizes this to all merge methods. There are <a class="reference external" href="https://docs.gitlab.com/ce/development/feature_flags/">feature flags</a>
for fallback to the previous way of doing if needed.
We expect these to be generally more performant and robust,
and also easier on the development side. On the other hand, some
tuning might be needed, since they increase the workload of HGitaly.</p>
<p>This leaves repository imports, pull-mirrors and a couple of simple
housekeeping methods to be done. It is reasonable to schedule that for
Heptapod 1.2.</p>
<p>Using HGitaly as the receptacle for end-user pushes will then be a
serious endeavor, and we expect some work to be done at the
transport/network level as well.</p>
</div>
<div class="section" id="mercurial-deeper-integrations">
<h2>Mercurial deeper integrations</h2>
<p>There is a lot of workflow related things and more generally of deeper
integration of Mercurial concepts in the application to be done.</p>
<p>For many of them, it does not really make sense to start development
until the major HGitaly work is fully finished, so that it can be done
on a clean ground.
For instance, advanced behaviours
of Merge Requests for stacked topics will need first all the MR logic to be
the sole responsibility of HGitaly.</p>
<p>We will thus really turn to them in the second semester of 2024.</p>
<p>Some simple features can be done earlier, though. An example would be
to display the phase of a changeset in the commit view. We will not
have much bandwidth to spare until we have finished catching up on
upstream, but we will consider contributions.</p>
<p>Thanks for reading, we wish you a happy year!</p>
</div>
Heptapod 0.40.0 released2023-12-04T00:00:00+01:002023-12-04T00:00:00+01:00Georges Racinettag:heptapod.net,2023-12-04:/heptapod-0.40.html<p>Heptapod 0.40.0 (final) was released today. This release saw us
reaching an important milestone, as we stopped mirroring Mercurial
repositories to Git by default. More about this below.</p>
<p>We're also jumping from GitLab 15.11 to 16.2 and bumping
Mercurial to 6.5.</p>
<p>The release candidate was …</p><p>Heptapod 0.40.0 (final) was released today. This release saw us
reaching an important milestone, as we stopped mirroring Mercurial
repositories to Git by default. More about this below.</p>
<p>We're also jumping from GitLab 15.11 to 16.2 and bumping
Mercurial to 6.5.</p>
<p>The release candidate was installed on <a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a> a week
ago, the final version will be installed on <a class="reference external" href="https://about.heptapod.host">heptapod.host</a> on 2023-12-05.</p>
<p>Heptapod 0.40.0 can be installed as a
<a class="reference external" href="https://hub.docker.com/r/octobus/heptapod/tags?page=1&name=0.40.0&ordering=last_updated">Docker image</a>
and
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/heptapod-0.40.0/INSTALL_HEPTAPOD.md">from source</a>.</p>
<p>The full changelog is available as usual <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/heptapod-0.40.0/HEPTAPOD_CHANGELOG.md">alongside the sources</a>.</p>
<p>Many thanks to all the people involved to make this happen!</p>
<div class="section" id="end-of-the-mirroring-to-an-internal-auxiliary-git-repository">
<h2>End of the mirroring to an internal auxiliary Git repository</h2>
<div class="section" id="background">
<h3>Background</h3>
<p>In its early prototype, Heptapod was fully relying on converting the
Mercurial repository to Git. We then introduced HGitaly, our internal
Mercurial content server. HGitaly is designed to be as transparent as possible
for other GitLab components, which are meant to interact with Gitaly,
GitLab's internal Git handling system. In practice, this means that
HGitaly implements the same gRPC protocol as Gitaly.</p>
<p>We have been since then implementing the needed gRPC methods one after
the other, first limiting Mercurial content description to changeset
hashes, then adding file content and listing capabilities while
keeping up to date with evolutions of the Gitaly protocol and planning
how we will gradually switch over to using HGitaly instead of an
auxiliary Git repository.</p>
<p>More details about this can be read in
<a class="reference external" href="/the-road-to-fully-native-mercurial-in-heptapod.html#the-road-to-fully-native-mercurial-in-heptapod">The road to fully native Mercurial in Heptapod</a>.
We have been running some projects with the <tt class="docutils literal">:hg_without_git</tt> feature
flag for a while, including Heptapod's own developmenet repository,
but HGitaly was lately still lacking a few specialized methods.</p>
</div>
<div class="section" id="changes-in-heptapod-0-40">
<h3>Changes in Heptapod 0.40</h3>
<p>In this version, we closed the latest gap, namely project license
detection, which is of course an expected basic feature of GitLab, and
to be fair, to most forges around. This analysis was still being
performed by Gitaly, which of course expects a Git repository.
We finally added the same functionality to HGitaly, our internal Mercurial
content server, using the same detector as Gitaly does, in
order to get the same results.</p>
<p>Once that was done, we changed the default value of the <tt class="docutils literal">:hg_without_git</tt>
feature flag to <tt class="docutils literal">true</tt>, effectively disabling the conversion to Git
by default.</p>
<p>An immediate benefit for native Mercurial projects is a much, much faster
push to Heptapod, as the conversion to Git was well known to be the
main bottleneck, to the point that we were running all repositories
above 100k changesets without it already.</p>
</div>
<div class="section" id="exceptions">
<h3>Exceptions</h3>
<p>Some projects still undergo conversion to Git, namely:</p>
<ul class="simple">
<li>"Legacy (hg-git based)" projects. Creation of these has been disabled
by default a couple of years ago in favor of "native" Mercurial
projects. Existing such projects still have to be explictely converted to
native. See the <a class="reference external" href="/help-us-polishing-the-native-migration#article-content">native migration post</a> for detailed explanations
about this.</li>
<li>Native Mercurial projects for which the "Legacy conversion to Git"
setting has been selected. The main use case is helping pushing to
external Git centric services.</li>
</ul>
<p>It is also possible to switch back the <tt class="docutils literal">hg_without_git</tt> flag to
<tt class="docutils literal">false</tt>, or to define exceptions for certain projects, by using the
<tt class="docutils literal">hg_with_git_fallback</tt> feature flag for them. In that case, users
should first perform the necessary catch-up to bring the auxiliary Git
repository up to date with latest changes in the Mercurial repository.
Explanations about this are given in
<a class="reference external" href="/the-road-to-fully-native-mercurial-in-heptapod.html#the-road-to-fully-native-mercurial-in-heptapod">The road to fully native Mercurial in Heptapod</a>.</p>
</div>
</div>
<div class="section" id="future-moves">
<h2>Future moves</h2>
<p>We plan to remove the <tt class="docutils literal">hg_without_git</tt> feature flag completely in
Heptapod 0.41. This is actually already the case in the main Heptapod
development branch.</p>
<p>Once that is released, this will be the end of a long journey, but
that is definitely not the end of the road.</p>
<p>Further HGitaly groundwork will now be focused on implementing write
methods that are currently relying on external <tt class="docutils literal">hg</tt> processes so
that the Web application does not need to have direct access to the
repositories any more. Once that is done, we can enjoy the benefits
that Gitaly brought to GitLab:
independent scalabilty of components and <a class="reference external" href="https://about.gitlab.com/topics/cloud-native/">Cloud Native</a>
deployments.</p>
<p>This further goal is also known as the <a class="reference external" href="https://foss.heptapod.net/groups/heptapod/-/milestones/45">HGitaly3</a> milestone. We are
currently working on the core requirements to let HGitaly perform
repository mutating tasks, so keep posted!</p>
<p>At some point later in the future, probably after Heptapod 1.0, we
will consider making the migration to native automatic, which should
allow us eventually to finally shed the technical debt of the
prototyping phase of Heptapod.</p>
</div>
<div class="section" id="conclusion">
<h2>Conclusion</h2>
<p>Because such an important breakthrough occurred in Heptapod 0.40, we
are close to be able to underline it further.</p>
<p>We don't want to make hasty promises, but it looks more and more
like there will not be a Heptapod 0.42 release. Whether that is
coincidential or the mark of destiny or irrelevant is left to the reader
appreciation.</p>
<p>Thank you for reading so far!</p>
</div>
Help us polishing the native migration2023-06-09T00:00:00+02:002023-06-09T00:00:00+02:00Georges Racinettag:heptapod.net,2023-06-09:/help-us-polishing-the-native-migration.html<p>We are calling out for beta testing of the data migration that makes
Projects eventually not need the <a class="reference external" href="/pages/faq.html#inner-git">auxiliary conversions to Git</a>.</p>
<p>This article is intended for our early adopters. If your Heptapod
instance was created at version 0.25 or later, it is unlikely that
you have any concerned …</p><p>We are calling out for beta testing of the data migration that makes
Projects eventually not need the <a class="reference external" href="/pages/faq.html#inner-git">auxiliary conversions to Git</a>.</p>
<p>This article is intended for our early adopters. If your Heptapod
instance was created at version 0.25 or later, it is unlikely that
you have any concerned Project.</p>
<div class="section" id="background">
<h2>Background</h2>
<p>In the dark ages of Heptapod, before <a class="reference external" href="https://foss.heptapod.net/heptapod/hgitaly">HGitaly</a> saw the light, Mercurial
repositories were systematically synchronized to an internal Git
repository that served as a view used by the Web application to
present repository content. This allowed us to get a working prototype
very quickly, but has lots of drawbacks, in user experience as well as
in performance and server administration.</p>
<p>Since then, we've introduced native Mercurial projects, in which
Mercurial repository content is exposed to the
Web application by a separate service called <a class="reference external" href="https://foss.heptapod.net/heptapod/hgitaly">HGitaly</a>, pretty much
in the same way that Git repository content is exposed to GitLab by
the <a class="reference external" href="https://docs.gitlab.com/ce/administration/gitaly/">Gitaly</a> service.</p>
<p>In version 0.25 (September, 2021), Heptapod has switched long ago to
native Mercurial projects by default,
but that affected only the project creation. In other words, projects
that were created earlier than that are still based on the convertion
from Mercurial to Git and have to be manually migrated to become
native.</p>
<p>To go in-depth on these topics, see <a class="reference external" href="/the-road-to-fully-native-mercurial-in-heptapod.html#the-road-to-fully-native-mercurial-in-heptapod">The road to fully native
Mercurial in Heptapod</a>.</p>
<p>Heptapod does ship with a data migration to make a Mercurial project
native, but it is still deemed to be experimental and therefore not
exposed in the Web UI. We've run it on the instances that we managed
directly, of course, but there is only so much we can cover ourselves.
The main objective
of this post is to request feedback from the users community so that
we can iron out the remaining problems and make it mainstream,
hopefully by exposing it in the Web UI in version 0.38 or 0.39.</p>
<p>Data migrations are always a pain to develop and maintain, as it is
very hard to cover all corner cases, especially with a data model so rich and
interconnected as GitLab's. That is why we really need to
get more feedback before taking the next step.</p>
</div>
<div class="section" id="how-to-check-if-a-mercurial-project-is-native">
<h2>How to check if a Mercurial Project is native</h2>
<p>The home page of a Project displays its
Version Control System (VCS) type right next to its name.</p>
<p>You will see <tt class="docutils literal">hg</tt> for a native Mercurial Project and <tt class="docutils literal">hg (legacy)</tt>
for a Project entirely based on conversions to Git.</p>
<div class="figure">
<img alt="Home page of a native Mercurial Project, displaying "hg"" class="screenshot" src="https://heptapod.net/images/project-vcs-type-hg-native.png" />
<p class="caption">Native Mercurial Projects display "hg" on their home pages.</p>
</div>
<div class="figure">
<img alt="Home page of a legacy (hg-git based) Mercurial Project, displaying "hg (legacy)"" class="screenshot" src="https://heptapod.net/images/project-vcs-type-hg-legacy.png" />
<p class="caption">Legacy (hg-git based) Mercurial Projects display "hg (legacy)" on their
home pages.</p>
</div>
<p>For some Systems Administrators, it might also be more convenient to query
directly using SQL the <tt class="docutils literal">vcs_type</tt> column of the <tt class="docutils literal">projects</tt> table.
The values are <tt class="docutils literal">hg_git</tt> for legacy Mercurial Projects based on the
inner conversion to Git and just <tt class="docutils literal">hg</tt> for native Mercurial
Projects. Guessing the value for Git projects is left to the reader.</p>
<p>For instance, here is the current breakdown of <a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a>:</p>
<pre class="literal-block">
# SELECT vcs_type, COUNT(*) FROM projects GROUP BY vcs_type
ORDER BY vcs_type;
vcs_type | count
----------+-------
git | 13
hg | 146
hg_git | 318
(3 rows)
</pre>
<p>This example also discloses two interesting facts about
<a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a> (see below for more details).</p>
</div>
<div class="section" id="what-to-migrate">
<h2>What to migrate</h2>
<p>Please consider that all data migrations are at least mildly
dangerous, ensure that your backups are in good shape and proceed gradually:</p>
<p>Start with small projects with a moderate amount of traffic, then
ramp it up carefully, preferably after you get end-user feedback.</p>
<p>If you have legacy Mercurial Projects with tens of thousands of
files and changesets, you may want to watch carefully how the HGitaly
service behaves, as there are currently performance issues being
addressed (see <a class="reference external" href="https://foss.heptapod.net/heptapod/hgitaly/-/issues/118">RHGitaly</a>).
Needless to say, subscribing to Octobus support can also help a lot at
this scale.</p>
</div>
<div class="section" id="the-migration-to-native">
<h2>The migration to native</h2>
<p>What the migration is actually meant to do is to replace every
occurrence of a Git commit hash by its corresponding Mercurial
changeset hash (formally called Node ID).</p>
<p>Perhaps the most prominent relevant data are Issues, Merge Requests
and Notes (comments), as they are partly due to user input.
There are many more such references
internally, notably in CI/CD objects, as the hash <em>is</em> the primary key
used to address commits.</p>
<div class="section" id="general-properties">
<h3>General properties</h3>
<ul class="simple">
<li>The migration is at the time of this writing to be run from the
command line, for a single project.</li>
<li>The migration is not reversible. Once it has reached a certain
stage, it will not rollback if an error occurs. Currently, this point of no
return is set at the migration of Merge Requests: once that is done,
there is no turning back.</li>
<li>The migration is designed to be idempotent. The intent is that
problematic data can be corrected by running a fixed version of
the migration. Therefore, reporting on your errors is the way to
have them fixed.</li>
</ul>
</div>
<div class="section" id="running">
<h3>Running</h3>
<p>The migration is available as the
<tt class="docutils literal">heptapod:experimental:hg_migrate_native</tt>
<a class="reference external" href="https://docs.gitlab.com/ce/raketasks/">Rake task</a>. It takes one mandatory and two optional arguments:</p>
<ul class="simple">
<li>The first argument, is the numeric id of the Project to migrate</li>
<li>The second argument is a boolean, defaulting to <tt class="docutils literal">false</tt>.
When set to <tt class="docutils literal">true</tt>, it allows
running the migration again if the Project has already been
migrated.</li>
<li>The third argument is the <tt class="docutils literal">username</tt> to be recorded as the user that
ran the migration. It defaults to <tt class="docutils literal">root</tt>.</li>
</ul>
<p>With the Omnibus and Docker images, one can run it as, e.g:</p>
<pre class="literal-block">
gitlab-rake heptapod:experimental:hg_migrate_native'[23]'
</pre>
<p>To run again after fixing a problem, that would be:</p>
<pre class="literal-block">
gitlab-rake heptapod:experimental:hg_migrate_native'[23,true]'
</pre>
<p>In case the instance is installed from source, replace <tt class="docutils literal"><span class="pre">gitlab-rake</span></tt>
by <tt class="docutils literal">bundle exec rake</tt> instead.</p>
</div>
<div class="section" id="checking-for-errors">
<h3>Checking for errors</h3>
<p>The migration will list problematic content on <tt class="docutils literal">stdout</tt> or
<tt class="docutils literal">stderr</tt>.</p>
<p>More details are available in the <tt class="docutils literal">heptapod_native_migration_logs</tt> table.</p>
<p>Please also try and open the problematic content in a Web browser
to help us assess the severity of the problem.</p>
</div>
<div class="section" id="making-it-mainstream">
<h3>Making it mainstream</h3>
<p>When we have enough feedback and undoubtely have corrected at least a
few quirks, we will no sooner than in Heptapod 0.38:</p>
<ul class="simple">
<li>Allow Project Owners to run the migration from the Project Settings,
alongside "Archive Project", "Transfer Project", etc.</li>
<li>remove <tt class="docutils literal">experimental</tt> from the Rake task name.</li>
</ul>
<p>Later on, we'll allow the Rake task to run in bulk.</p>
<p>In the far future, we'll migrate the remaining last legacy projects
automatically.</p>
</div>
</div>
<div class="section" id="the-state-of-native-mercurial-on-foss-heptapod-net">
<h2>The state of native Mercurial on foss.heptapod.net</h2>
<p>As it can be seen above, there are still lots of legacy Mercurial
Projects on foss.heptapod.net, and that is perhaps a surprise, given
that this instance is generally the most bleeding edge around, often
running the latest release candidate.</p>
<p>So, of course it was the first to run the migration ever, and the
Heptapod development Projects were among the first to go
native. However, even over there, we need to be cautious:</p>
<ul class="simple">
<li>We host some large developement communities (PyPy notably). This
means that some coordination has to be done.</li>
<li><a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a> has some of the largest Mercurial repositories
of any Heptapod instance. The conversion to Git is by orders of
magnitude the main bottleneck in <em>pushes</em>. On the other hand,
removing it places the load on the relatively young HGitaly service.
We've reached the limits of HGitaly on foss.heptapod.net some time
ago – this was the primary motivation for the development of an
ultra fast, lean and non-blocking pure Rust implementation:
RHGitaly. We're now waiting for the likes of
<a class="reference external" href="https://foss.heptapod.net/heptapod/hgitaly/-/issues/127">FindCommit</a> and <a class="reference external" href="https://foss.heptapod.net/heptapod/hgitaly/-/issues/129">TreeEntry</a> to land in production to proceed further.</li>
</ul>
</div>
<div class="section" id="final-words">
<h2>Final words</h2>
<p>Thank you for reading so far!</p>
<p>We're truly excited about your Projects finally ditching their Git
crutches. Also, we realize that all of this is extra work for our
early adopters, and we thank you heartily, as Heptapod probably wouldn't
exist without you.</p>
</div>
Heptapod 0.30.0 released2022-03-22T00:00:00+01:002022-03-22T00:00:00+01:00Georges Racinettag:heptapod.net,2022-03-22:/heptapod-0.30.html<p>Heptapod 0.30.0 (final) was released today. This is a fairly simple
release, focusing on GitLab and Mercurial version bumps.</p>
<p>This time we're jumping from GitLab 14.6 to 14.8, in order to get more
time for Heptapod-specific development in the next cycles.</p>
<p>The update from Mercurial 6 …</p><p>Heptapod 0.30.0 (final) was released today. This is a fairly simple
release, focusing on GitLab and Mercurial version bumps.</p>
<p>This time we're jumping from GitLab 14.6 to 14.8, in order to get more
time for Heptapod-specific development in the next cycles.</p>
<p>The update from Mercurial 6.0 to 6.1 is especially important for us,
as it brings very significant performance improvements in pushes with
the core now taking obsolescence into account in heads
computations. This allows us to stop fixing the heads after the fact, which
was very costly.</p>
<p>The release was installed immediately on
<a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a>, and will be installed on <a class="reference external" href="https://about.heptapod.host">heptapod.host</a> the
following day, March 23th.</p>
<p>Heptapod 0.30.0 can be installed as a
<a class="reference external" href="https://hub.docker.com/r/octobus/heptapod/tags?page=1&name=0.30.0&ordering=last_updated">Docker image</a>
and
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/heptapod-0.30.0/INSTALL_HEPTAPOD.md">from source</a>.</p>
<p>The full changelog is available as usual <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/branch/heptapod-0-30/HEPTAPOD_CHANGELOG.md">alongside the sources</a>.</p>
<p>Many thanks to all the people involved to make this happen!</p>
Heptapod 0.29 released and general development news2022-02-24T00:00:00+01:002022-02-24T00:00:00+01:00Georges Racinettag:heptapod.net,2022-02-24:/heptapod-0.29.html<p>The release last week of Heptapod 0.29.0 provides a good opportunity
to look back at what happened since the previous of these announcements
and point out the subjects that we will focus on in the next
development cycles. Since then we also released Heptapod 0.29.1 to …</p><p>The release last week of Heptapod 0.29.0 provides a good opportunity
to look back at what happened since the previous of these announcements
and point out the subjects that we will focus on in the next
development cycles. Since then we also released Heptapod 0.29.1 to
include security updates from upstream GitLab.</p>
<p>The major advances made since Heptapod 0.26 are about native
Mercurial support and commercial CI/CD with Clever Cloud for
<a class="reference external" href="https://about.heptapod.host">heptapod.host</a>. These are explained in details in this post, but
first things first…</p>
<div class="section" id="heptapod-0-29">
<h2>Heptapod 0.29</h2>
<p>Heptapod 0.29 brings in GitLab 14.6, exposes for the first time the
migration of Mercurial legacy projects (with Git conversion) to native,
and removes the intermediate HGitaly1 running mode of Mercurial native
projects (more on the native Mercurial topic below).</p>
<p>Heptapod 0.29.0 was installed on February 22nd on
<a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a> and <a class="reference external" href="https://about.heptapod.host">heptapod.host</a>. The follow-up 0.29.1 was
installed on February 28th.</p>
<p>Heptapod 0.29.1 can be installed as a
<a class="reference external" href="https://hub.docker.com/r/octobus/heptapod/tags?page=1&name=0.29.1&ordering=last_updated">Docker image</a>
and
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/heptapod-0.29.1/INSTALL_HEPTAPOD.md">from source</a>.</p>
<p>The full changelog is available as usual <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/heptapod-0.29.1/HEPTAPOD_CHANGELOG.md">alongside the sources</a>.</p>
<p>Many thanks to all the people involved to make this happen!</p>
</div>
<div class="section" id="mercurial-native-projects">
<h2>Mercurial native projects</h2>
<p>Early Heptapod versions were exposing all Mercurial content to the
GitLab web application by converting it internally to Git. This was a
great move to quickly evaluate the potential of such a solution, with
two obvious drawbacks:</p>
<ul class="simple">
<li>most commit identifiers (hashes) in the Web
user interface were Git commit hashes, not obviously related to what
users can see in their local repositories.</li>
<li>the conversion to Git is an unacceptable overhead.</li>
</ul>
<p>Since then, we've introduced "native" Mercurial projects, which don't
have the first problem, because the commit identifiers handled by
GitLab are Mercurial changeset hashes, but still rely on the Git
conversion for some operations.</p>
<p>To this day, Heptapod still
supports the first way of doing things, in the form of
Projects with the "Mercurial (legacy with Git conversion)" VCS type.</p>
<p>Much more background on this is given in <a class="reference external" href="/the-road-to-fully-native-mercurial-in-heptapod.html#the-road-to-fully-native-mercurial-in-heptapod">The road to fully native Mercurial
in Heptapod</a>. It boils down to this:</p>
<ul class="simple">
<li>our plan is to gradually improve how much native Mercurial projects
truly are native, up to the point where Git is not involved at all.</li>
<li>The minimal viable support level for native Mercurial projects is
called "HGitaly1" (introduced in Heptapod 0.17).</li>
<li>the only heavy data migration occurs while making a Project
native. In other words, there are no persistent references to Git
content in the database.</li>
</ul>
<p>In the <a class="reference external" href="heptapod-0.26">announcement following the 0.26.0rc1 release</a>,
we were saying that the internal infrastructure was in place to drop the
conversion of Mercurial content to an internal auxiliary Git
repository, and therefore that Heptapod 1.0 was in sight.</p>
<p>Here is a summary of what happened on that front in the releases since then:</p>
<ul class="simple">
<li>0.27: this release was focused on unrelated matters (leap
to GitLab 14.4 and Mercurial push-mirror feature).</li>
<li>0.28: the HGitaly1 mode was disabled by default.</li>
<li>0.28: exposition of the mode without Git, with explicit
activation by feature flags.</li>
<li>0.28: major progress in the migration to native Mercurial
(runnable by systems administrators only).</li>
<li>0.28: relabeling of VCS Type labels, so that a "Mercurial
Project" means a native Mercurial project.</li>
<li>0.29: removal of the HGitaly1 mode.</li>
<li>0.29: the migration to native Mercurial is now exposed in the REST
API, hence available to all Project Maintainers (caution advised).</li>
</ul>
<p>We also made a few interesting experiments in that time frame. For a
very long time, we've been stating that Heptapod was able to host
projects in the 100k changesets ballpark. The main reason for that was
precisely the conversion to Git. For instance, the import of PyPy
(about 100k changesets) into <a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a> took more than 4
hours.</p>
<p>As soon as there was a way to stop
it, we've turned to one of our favorite projects for Mercurial
scalability measures: <a class="reference external" href="https://hg.mozilla.org/mozilla-central/">mozilla-central</a> (around 600k
changesets). Unsurprisingly, its import to a development Heptapod
instance took about half an hour, same time as a <tt class="docutils literal">hg clone</tt> not
involving Heptapod. In the same vein, importing the repository used by
Octobus for development of Mercurial itself (about 51k changesets)
only takes about one minute.</p>
</div>
<div class="section" id="builtin-ci-cd-on-heptapod-host">
<h2>Builtin CI/CD on heptapod.host</h2>
<p>In the time frame between Heptapod 0.26 and 0.29, we've devoted some time
to work on Heptapod PAAS Runner, and more specifically on its Clever
Cloud variant.</p>
<p>The end goal was to provide a builtin ready-made CI/CD as
part of our commercial offering on <a class="reference external" href="https://about.heptapod.host">heptapod.host</a>.</p>
<p>Of course, users of heptapod.host have always been able to host their
own Heptapod Runners and register them at the Project or Group level,
and that is still possible.</p>
<p>But we knew that it wasn't enough. Not everybody has the will to
maintain the needed infrastructure, be it made of virtual machines or
bare metal. Moreover, in many concrete cases, the fixed costs that are
incurred cannot be justified by the actual running time of the CI/CD.</p>
<p>The end result is that today, all that users of <a class="reference external" href="https://about.heptapod.host">heptapod.host</a> have to do
to get the CI/CD to work is to activate the shared runners for their
Groups or Projects.</p>
<p>Billing happens by the second and the size of the running VMs (also
known as "flavor") can be specified through job variables.</p>
<p>More detail (and examples!) are available in our dedicated
page, <a class="reference external" href="/pages/clever-cloud-runner#clever-cloud-runner">Clever Cloud Runner documentation</a>.</p>
</div>
<div class="section" id="other-changes-occurring-since-heptapod-0-26">
<h2>Other changes occurring since Heptapod 0.26</h2>
<p>It has become routine, but it wouldn't be fair to the amount of work
involved not to mention upstream GitLab version updates: we went from
GitLab 14.2 in Heptapod 0.26 to GitLab 14.6 in Heptapod 0.29.</p>
<p>Another interesting feature is the Mercurial push mirror capability,
introduced in Heptapod 0.27. It can be used for instance to position
Heptapod as an upstream working area, pushing automatically to an
existing canonical repository.</p>
</div>
<div class="section" id="development-areas-in-the-next-few-releases">
<h2>Development areas in the next few releases</h2>
<p>Of course we will continue to keep Heptapod up to date with respect to
its upstream, with GitLab 14.7 required for March 22nd and GitLab 14.8 for
April 22nd.</p>
<div class="section" id="native-mercurial">
<h3>Native Mercurial</h3>
<p>The fact that we are still depending on Git is the thing that prevents
us from claiming the 1.0 version.</p>
<p>As of Heptapod 0.29, the only feature that we are lacking to stop by
default the conversion to Git for native projects is the programming
languages statistics. As was already mentioned in the Heptapod 0.26
announcement, we'll have to develop a Mercurial extension providing
the same functionality as <a class="reference external" href="https://github.com/github/linguist">GitHub Linguist</a> for this.</p>
<p>We will probably keep on opening up the migration of existing projects
to native Mercurial, by providing a Web user interface for it in one
of the two next releases.</p>
</div>
<div class="section" id="better-support-of-drive-by-contribution">
<h3>Better support of drive-by contribution</h3>
<p>We will start working soon on the plan to allow contribution without
being granted the Developer role.</p>
<p>The plan relies on implementing <a class="reference external" href="https://www.mercurial-scm.org/wiki/TopicPlan#sub_branches.2C_namespacing_and_representation">topic namespaces</a>, in
the <tt class="docutils literal">topic</tt> extension itself, and mapping them automatically to
Heptapod users, thus creating the notion of personal namespaces.</p>
<p>People with the Reporter role will be allowed automatically to push on
topics in their personal namespaces, and create Merge Requests from
them. By default, all authenticated users have the Reporter role on
public projects.</p>
</div>
<div class="section" id="mercurial-6-1">
<h3>Mercurial 6.1</h3>
<p>Including Mercurial 6.1 in Heptapod will have a major positive
performance impact on projects with lots of active branches.</p>
<p>Current testing on Mercurial 6.1rc0 indicates that it will work right
away: all our internal and end-to-end tests are already
passing. Unless there is a nasty surprise, Mercurial 6.1 will be
included in Heptapod 0.30, which is due on March 22nd.</p>
</div>
</div>
Heptapod 0.26.0rc1 released, 1.0 now in sight2021-10-27T00:00:00+02:002021-10-27T00:00:00+02:00Georges Racinettag:heptapod.net,2021-10-27:/heptapod-0.26.html<p>The release today of Heptapod 0.26.0rc1 brings in ground work for the
fully native Mercurial support and the new "Mercurial Publisher"
role. Read below for more details about these.</p>
<p>As we announced earlier, this new series does not include an upstream
GitLab version change. Instead we boosted Python …</p><p>The release today of Heptapod 0.26.0rc1 brings in ground work for the
fully native Mercurial support and the new "Mercurial Publisher"
role. Read below for more details about these.</p>
<p>As we announced earlier, this new series does not include an upstream
GitLab version change. Instead we boosted Python to 3.9 and Mercurial
to 5.9. Don't miss the related changes in the procedure to install
from source.</p>
<p>The release candidate was installed on October 26th on
<a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a>. The final version will be installed
simultaneously on <a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a> and <a class="reference external" href="https://about.heptapod.host">heptapod.host</a>.</p>
<p>Heptapod 0.26.0rc1 can be installed as a
<a class="reference external" href="https://hub.docker.com/r/octobus/heptapod/tags?page=1&name=0.26.0rc1&ordering=last_updated">Docker image</a>
and
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/heptapod-0.26.0rc1/INSTALL_HEPTAPOD.md">from source</a>.</p>
<p>The full changelog is available as usual <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/branch/heptapod-0-26/HEPTAPOD_CHANGELOG.md">alongside the sources</a>.</p>
<p>Many thanks to all the people involved to make this happen!</p>
<div class="section" id="the-new-mercurial-publisher-role">
<h2>The new "Mercurial Publisher" role</h2>
<p>This release introduces a new "Mercurial Publisher" access level, that
can be selected in membership pages for Groups and Mercurial
Projects. It sits between Developer and Maintainer</p>
<p>As the name should suggest, the effect is to allow pushing public
changesets or changesets that will be automatically published. With
the <a class="reference external" href="/pages/faq.html#bare-draft">default workflow of Heptapod</a>, this
boils down to changesets without topics.</p>
<p>In Heptapod 0.26.0 (final), the Mercurial Publisher role can be
selected in protected branches settings. This was not true of in
release candidates.</p>
<p>See also the <a class="reference external" href="https://foss.heptapod.net/help/user/permissions.html">online documentation</a>.</p>
</div>
<div class="section" id="preparations-to-drop-the-conversion-to-git">
<h2>Preparations to drop the conversion to Git</h2>
<p>As explained in <a class="reference external" href="/the-road-to-fully-native-mercurial-in-heptapod.html#the-road-to-fully-native-mercurial-in-heptapod">The road to fully native Mercurial in Heptapod</a>,
Mercurial repository content is still converted to this day to an
auxiliary Git repository, even for "fully native" Mercurial projects.</p>
<p>Heptapod 0.26 does not change that, but it contains all the internal
infrastucture changes to do so, with the introduction of a single
switch to flip, currently more akin to a circuit board fuse to blow
than to the neat red one that is shining on your power conditioner.
Yet this makes for a fair amount of changes in itself (<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/merge_requests/289">heptapod!289</a>,
<a class="reference external" href="https://foss.heptapod.net/heptapod/py-heptapod/-/merge_requests/65">py-heptapod!65</a>), that we will be happy to stabilize ahead of time.</p>
<p>Another benefit of this effort is that we now have a clear picture of
what is still missing in HGitaly, and it's not much:</p>
<ul class="simple">
<li>support for programming languages detection. For that purpose,
GitLab uses the very Git centric <a class="reference external" href="https://github.com/github/linguist">GitHub Linguist</a> Ruby library. We
will need a Mercurial extension providing the same
functionality. There's a good chance we'll create it ourselves, and
if that happens, it will be released separately for the benefit of
the broader community.</li>
<li>support for <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/issues/437">checked-in attributes</a>. In
truth, we can ignore it, as Mercurial projects don't recognize any
such things and it is unlikely that many have a <tt class="docutils literal">.gitattributes</tt>, to
rely on the default GitLab support of them.</li>
<li>a few repository content searching methods that are not widely used
within the GitLab code base yet.</li>
</ul>
<p>Closing this gap will probably have us celebrate and label the
corresponding version as Heptapod 1.0.</p>
</div>
<div class="section" id="roadmap-towards-heptapod-1-0">
<h2>Roadmap towards Heptapod 1.0</h2>
<p>With GitLab 14.2 being scheduled for end of life on November 22nd,
we will have to switch back our focus to catching up with upstream.</p>
<p>It is therefore unlikely that Heptapod 0.27 can provide the option to
unplug the Git repository, and even less to make it standard but
Heptapod 0.28 probably will.</p>
<p>All in all, we can now expect Heptapod 1.0 to happen around the end of
this year, perhaps in lieu of 0.29 or 0.30.</p>
</div>
<div class="section" id="in-conlusion">
<h2>In conlusion</h2>
<p>Thank you for your attention, and don't hesitate to give us feedback
about the subjects mentioned above.</p>
</div>
Heptapod 0.25.0 released, featuring GitLab 14.22021-09-21T00:00:00+02:002021-09-21T00:00:00+02:00Georges Racinettag:heptapod.net,2021-09-21:/heptapod-0.25.html<p>We're glad to announce the release of Heptapod 0.25.0, based on GitLab
14.2 and making Mercurial native projects the default for creations.</p>
<p>As <a class="reference external" href="/heptapod-0.24.html#migrating-existing-instances">previously explained</a>, to upgrade an existing instance to 0.25, one
needs to start from a Heptapod 0.24 instance whose background
migrations have …</p><p>We're glad to announce the release of Heptapod 0.25.0, based on GitLab
14.2 and making Mercurial native projects the default for creations.</p>
<p>As <a class="reference external" href="/heptapod-0.24.html#migrating-existing-instances">previously explained</a>, to upgrade an existing instance to 0.25, one
needs to start from a Heptapod 0.24 instance whose background
migrations have already fully run.</p>
<p>Read below for more details about this release and have a glimpse of
the close future.</p>
<p>Heptapod 0.25.0 can be installed as a
<a class="reference external" href="https://hub.docker.com/r/octobus/heptapod/tags?page=1&name=0.25.0&ordering=last_updated">Docker image</a>
and
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/heptapod-0.25.0/INSTALL_HEPTAPOD.md">from source</a>.</p>
<p>The full changelog is available as usual <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/branch/heptapod-0-25/HEPTAPOD_CHANGELOG.md">alongside the sources</a>.</p>
<p>Thanks alot to the people that have contributed to this version.</p>
<div class="section" id="prime-time-for-mercurial-native-projects">
<h2>Prime time for Mercurial native projects</h2>
<p>Let's be really clear: this is only about new projects. Existing
projects are totally unaffected by the change explained in this section.</p>
<p>Heptapod can host two different types of Mercurial projects: the
"native" projects already feel as though no conversion to Git was
happening behind the scenes and will be carried over with no data
migration to the day we finally stop converting to Git as a technical
crutch. On the other hand, the non-native projects do rely on the
inner Git conversion for exposition to the web application, resulting
in various inconsistencies in the user experience (see <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/issues/6">heptapod#6</a>
for some of them).</p>
<p>Because the native Mercurial projects are relatively new, they were
until today's release stricly opt-in: instance Administrators had to
allow them explicitely in Application Settings. Similarly, the Group
settings for VCS type was by default set to non-native Mercurial.</p>
<p>With Heptapod 0.25.0, the native Mercurial VCS type takes the place of
the non-native one for Project creation both in the Application
Settings and in all Group settings. At this point we felt we had
enough testing of native projects, and that creating further
non-native ones had become a disservice to users.</p>
<p>Instance Administrators and Group Maintainers may revert that change,
although we'd advise not to do it except a serious problem has been
detected. In that latter case, we'd like to hear about it, naturally.</p>
<p>We won't change these settings again until we drop the support for
non-native projects, which lies way further in the future. What we may
do, though, is change the labels at some point, making non-native
Mercurial projects the ones being singled out.</p>
<p>As far as existing projects are concerned, we are working on a
migration system. It already shows some good results but still needs
to be completed.</p>
<p>More information about native Mercurial in Heptapod and the plan to
get rid of all conversions to Git can be found in <a class="reference external" href="/the-road-to-fully-native-mercurial-in-heptapod.html#the-road-to-fully-native-mercurial-in-heptapod">The road to fully
native Mercurial in Heptapod</a>.</p>
</div>
<div class="section" id="the-close-future-ahead">
<h2>The close future ahead</h2>
<p>With Heptapod 0.25, we are based on an upstream GitLab version that
will receive security upgrades for two months from now.</p>
<p>This gives us some headroom to focus more on Heptapod features and
less on upstream upgrades. Namely, Heptapod 0.26 should still be on
GitLab 14.2, with next upstream version bump in Heptapod 0.27 only.</p>
<p>Here are some topics we may work on in the Heptapod 0.26 development
cycle:</p>
<ul class="simple">
<li>Improving the fully native mode of Mercurial projects. The ultimate
goal is naturally to get rid of Git conversions completely.</li>
<li>Merge Requests in cases where topics are stacked: <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/issues/63">heptapod#63</a>,
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/issues/284">heptapod#284</a>, <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/issues/366">heptapod#366</a>.</li>
<li>Per-user topic namespaces, making it possible to contribute without
the Developer role.</li>
</ul>
<p>If you are interested in contributing to these subjects, don't hesitate
to <a class="reference external" href="/pages/contact-us.html#contact-us">contact us</a>, for instance in
the "Development" Mattermost channel, or simply by commenting on the
relevant issues.</p>
<p>With roughly 5 weeks of development time and maturation, it is very
very likely that Heptapod 0.26 will provide these features in a
partial form, perhaps with explicit activation, but we hope to make
good progress. There are also lots of smaller improvements waiting in
the backlog.</p>
<p>Thank you for reading so far, and happy heptapoding.</p>
</div>
Heptapod 0.24.0rc1 released, moving to GitLab 142021-08-24T00:00:00+02:002021-08-24T00:00:00+02:00Georges Racinettag:heptapod.net,2021-08-24:/heptapod-0.24.html<p>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.</p>
<p>As all major GitLab version changes, this is a pivotal
version for upgrading existing instances. Please read below …</p><p>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.</p>
<p>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.</p>
<p>The release candidate was installed on August 24th on
<a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a>. The final version will be installed
simultaneously on <a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a> and <a class="reference external" href="https://about.heptapod.host">heptapod.host</a>.</p>
<p>Heptapod 0.24.0 will also be followed shortly by 0.25.0rc1, featuring
GitLab 14.1 and more features.</p>
<p>Heptapod 0.24.0rc1 can be installed as a
<a class="reference external" href="https://hub.docker.com/r/octobus/heptapod/tags?page=1&name=0.24.0rc1&ordering=last_updated">Docker image</a>
and
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/heptapod-0.24.0rc1/INSTALL_HEPTAPOD.md">from source</a>.</p>
<p>The full changelog is available as usual <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/branch/heptapod-0-24/HEPTAPOD_CHANGELOG.md">alongside the sources</a>.</p>
<div class="section" id="migrating-existing-instances">
<h2>Migrating existing instances</h2>
<p>As very clearly stated in upstream <a class="reference external" href="https://docs.gitlab.com/ee/update/index.html#upgrade-paths">recommendations</a>, 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.</p>
<p>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.</p>
<p>In terms of Heptapod versions, this translates to:</p>
<ul class="simple">
<li>upgrade to Heptapod 0.23 (GitLab 13.12), wait for background migrations to
complete</li>
<li>upgrade to Heptapod 0.24 (GitLab 14.0)</li>
<li>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.</li>
</ul>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p>Checking the status of background migrations can be done in the
Admin area <a class="reference external" href="https://docs.gitlab.com/ee/update/#checking-for-background-migrations-before-upgrading">from Heptapod 0.24 (GitLab 14.0) onwards</a>.</p>
<p>In earlier versions, from Heptapod 0.14 (GitLab 12.10) onwards, this has
to be done with the command-line.</p>
<ul class="last">
<li><p class="first">For Omnibus/Docker installations, as root:</p>
<pre class="literal-block">
gitlab-rails runner -e production 'puts Gitlab::BackgroundMigration.remaining'
</pre>
</li>
<li><p class="first">For source installations, as the proper system user and from the
Rails application directory:</p>
<pre class="literal-block">
bundle exec rails runner -e production 'puts Gitlab::BackgroundMigration.remaining'
</pre>
</li>
</ul>
</div>
</div>
<div class="section" id="heptapod-0-25-and-native-mercurial-projects">
<h2>Heptapod 0.25 and native Mercurial projects</h2>
<p>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.</p>
<p>Notably, we plan to make "native" Mercurial the norm for <em>new projects</em> 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.</p>
<p>More background about native and non-native projects can be found in
our previous article
<a class="reference external" href="/the-road-to-fully-native-mercurial-in-heptapod.html#the-road-to-fully-native-mercurial-in-heptapod">The road to fully native Mercurial in Heptapod</a>.
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.</p>
<p>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.</p>
<p>The tracking issue for this move is <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/issues/523">heptapod#523</a>.</p>
</div>
Heptapod Runner 0.4.0 released2021-05-21T00:00:00+02:002021-05-21T00:00:00+02:00Georges Racinettag:heptapod.net,2021-05-21:/heptapod-runner-040-released.html<p>We're glad to announce that Heptapod Runner 0.4.0 was released this
week, built for many <strong>more operating systems and architectures</strong>.
We're <strong>calling out</strong> to our users <strong>for testing</strong> of some of them.</p>
<p>Download links are available on the Heptapod <a class="reference external" href="/pages/get-heptapod#runner">download page</a></p>
<p>Thanks to all the people involved in …</p><p>We're glad to announce that Heptapod Runner 0.4.0 was released this
week, built for many <strong>more operating systems and architectures</strong>.
We're <strong>calling out</strong> to our users <strong>for testing</strong> of some of them.</p>
<p>Download links are available on the Heptapod <a class="reference external" href="/pages/get-heptapod#runner">download page</a></p>
<p>Thanks to all the people involved in making this release happen.</p>
<div class="section" id="an-upstream-version-leap">
<h2>An upstream version leap</h2>
<p>While Heptapod itself has been kept up to date with GitLab for a whole
year, now, Heptapod Runner stayed for a long time on an old
version. Namely, version 0.3 was based on upstream 12.10.</p>
<p>This is partly due to the fact that GitLab upgrades didn't break
compatibility, which we can certainly thank upstream about.</p>
<p>Among the reasons why we didn't follow closely upstream GitLab Runner
versions was the fact that we were using a hacked-down version of the
build system. It was simple enough to get us running for the early
days, but it didn't go well with upstream changes. On the other hand,
the upstream build got simpler in the mean time.</p>
<p>A related aspect that was slowing us down was that we didn't really
have control of the test suite. Of course the prerequisites for the
integration tests are more more complicated for a program that can be
thought as a meta-scheduler for several virtualization and
containerization techniques.</p>
<p>So now, Heptapod Runner 0.4.0 is based on GitLab Runner 13.3.2. We're
therefore not quite up to date, the current GitLab version being 13.11
as of this writing, but we are confident that the progress made in the
build and testing departments will allow us to perform upgrades much
faster, now.</p>
</div>
<div class="section" id="new-operating-systems-and-cpu-architectures">
<h2>New operating systems and CPU architectures</h2>
<p>An expected positive outcome of the work we've been doing on the build
system is that it also unblocked the cross compilations set up by
upstream, allowing us to publish many more official executables.</p>
<p>Up to now, we only had Heptapod Runner for Linux on x86_64 (amd64) and
aarch64 (arm64). To that list we can add the s390x architecture on
Linux, amd64 on Windows and finally Darwin (Mac OSX) for amd64 and
arm64.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">we don't have the images for Docker-based executors on
Windows yet. Probably just a matter of proper build context,
don't hesitate to contact us if you have a working build
setup for Windows Docker and want to help.</p>
</div>
<p>At this point, the Mac OSX builds have seen only quick tests with the
Shell executor and we don't have access to s390x hosts to do the same
under Linux. On the other hand, we've started using the Windows build
for continuous testing of Mercurial itself on <a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a>.</p>
<p>All other combinations are basically untested, but given how small and
high-level our changes with respect to GitLab
Runner actually are, there is no reason to doubt they would all
perform as expected, provided a suitable version of Mercurial and
hg-evolve is accessible.</p>
<p>So please, if you're interested if the undertested OSes and
architectures, don't hesitate to <a class="reference external" href="/pages/contact-us.html#contact-us">contact us</a> with your feedback or
questions!</p>
</div>
The road to fully native Mercurial in Heptapod2021-03-08T00:00:00+01:002021-03-08T00:00:00+01:00Georges Racinettag:heptapod.net,2021-03-08:/the-road-to-fully-native-mercurial-in-heptapod.html<p>What are native Mercurial projects? What does this "fully native"
qualifier you've seen here or there in our issues and merge requests
mean? How will Heptapod get there?</p>
<p>This is about getting rid of the side conversions to Git that Heptapod
performs under the hood, and the Heptapod 1.0 …</p><p>What are native Mercurial projects? What does this "fully native"
qualifier you've seen here or there in our issues and merge requests
mean? How will Heptapod get there?</p>
<p>This is about getting rid of the side conversions to Git that Heptapod
performs under the hood, and the Heptapod 1.0 landmark, actually.</p>
<p>Read below for perspective and to
learn how we will ship these important long term features.</p>
<div class="section" id="historical-perspective-and-ultimate-goals">
<h2>Historical perspective and ultimate goals</h2>
<p>The original Heptapod idea was to build on the fact that Git and
Mercurial aren't conceptually that different when accessing data at
the commit level. One-to-one conversion between Git commits and
Mercurial changesets is a long solved problem.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">in Mercurial terminology, what Git users usually call a
commit is called a changeset, whereas <tt class="docutils literal">commit</tt> is a
command that creates a changeset.</p>
</div>
<p>From a user's perspective, the main differences lie in how to address commits
symbolically (branches, tags, topics…) and what happens in pulls and
pushes. The case of a forge, even as rich as GitLab, should not be
much different.</p>
<p>All it took for the early Heptapod prototype to start displaying
Mercurial content was to expose it through an internal Git repository,
with a set of conventions to map Mercurial concepts to Git
branches. The application needs some entry points to address the
changesets, and of course GitLab expect Git branches and tags to play
that part. In truth, any web application would need something
alike anyway. Git refs in general provide exactly that.</p>
<p>An important point is that the auxiliary Git repository does <em>not</em> lie
in the data path between the client and server-side Mercurial
repositories.
The best way to think about it is to consider it is as a side view
meant for the web application, not that different in spirit with data
exchange performed in any serialization format.</p>
<p>This was good enough for a prototype, and we've been refining a lot
since then, but it has several drawbacks</p>
<ul class="simple">
<li>Mercurial to Git conversion is slow and does not scale with the
repository size.
This can especially be felt in imports of large repositories, but
we also pay a small price at every push.</li>
<li>If the web application does nothing more than displaying a Git
repository, we can expect all the hashes in the Web UI and the API
to be Git commit hashes.
We could in theory replace them by Mercurial changeset hashes in the
outer layers of the application, and we actually did it in a few
cases, but trying to be comprehensive would be an unbearable
maintainance burden. See <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/issues/6">heptapod#6</a> for more details.</li>
<li>Bad perception: some people believe that if Heptapod converts
to Git, they might as well use Git. Even the message that there is
no back-and-forth conversion to Git, that server-side Mercurial is
the source of truth is a bit complicated to convey efficiently.</li>
<li>In some cases, Mercurial is more flexible than Git, requiring, e.g.,
less locking but we get the worst of both worlds.</li>
</ul>
<p>It has been a major long term goal of the Heptapod project since then
to switch to a "native" way of handling Mercurial repositories, in
which no conversion to Git would be necessary.</p>
<p>To finish on this historical perspective, our early experiments
happened right before GitLab launched their <a class="reference external" href="https://docs.gitlab.com/ce/administration/gitaly/">Gitaly</a> project with the
goal to provide all access to Git content in a separate server
component. Because Gitaly can be remote from the web application
and sharded, it solves in particular the problem of server-side
horizontal scaling.</p>
<p>Gitaly is by no means meant
for VCS independency, but it makes for a neat separation of concerns,
and it would have been easier for us to start right away with the
Gitaly project already completed, as it was in GitLab 11.</p>
<p>Our plan is simple: implement a Gitaly server for Mercurial, a project
we called <a class="reference external" href="https://foss.heptapod.net/heptapod/hgitaly">HGitaly</a>. By doing this, the other GitLab components
should happily expose Mercurial content without much modifications. Of
course, we need to identify Mercurial projects and dispatch requests
to HGitaly instead of Gitaly for them, but that is well encapsulated
in a finite set of mostly stable inner application layers.</p>
<p>If we go as far as letting all the server-side writes be performed by
HGitaly, then Heptapod will also gain the nice horizontal scaling
properties that were the original goal of Gitaly, as well as so-called
container native deployments, which can be of interest for
small scale deployments as well. This is represented by the
<a class="reference external" href="https://foss.heptapod.net/groups/heptapod/-/milestones/45">HGitaly3</a> milestone, and is beyond the scope of this
article.</p>
</div>
<div class="section" id="hgitaly1-native-mercurial-projects">
<span id="native-hashes"></span><h2>HGitaly1: native Mercurial projects</h2>
<p>Several GitLab sub systems actually store Git commit hashes in the
database. For instance, a Merge Request keeps track of the commits
for its diff view. Moreover, user and system comments often reference
commits by hash directly. This is what happens, e.g., when a commit
cross-references an issue: the issue gets a system comment containing
the system hash. Moreover, any external system can keep a link to a
given commit, with the full hash in the URL, of course.</p>
<p>All of this means that we cannot simply make existing Mercurial projects go
through HGitaly and remove the auxiliary Git repository. Instead, we
needed to make a difference between "native" Mercurial projects,
internally exposed through HGitaly, and the traditional ones, internally
exposed through the Git conversion. For simplicity, we decided to make
that distinction a different VCS type, which was introduced in
Heptapod 0.17.</p>
<p>The piece of good news, though, was that all this adherence to persistent data
is limited to the commit hashes. On the other hand, the main user
experience problem in Heptapod is precisely that Git hashes
appear in various places of the interface, a condition worsened by the
fact that users can't predict them.
Finally, it is good software engineering practice to break
down long implementation endeavors in smaller chunks of work and ship
them early. That was a nice convergence.</p>
<p>So we defined an intermediate step, the <a class="reference external" href="https://foss.heptapod.net/groups/heptapod/-/milestones/43">HGitaly1</a> milestone in which
we introduced the "Mercurial (native)" VCS type with these properties:</p>
<ul class="simple">
<li>all content is still converted to Git</li>
<li>all commit hashes seen by the web application are actually Mercurial
changeset hashes</li>
<li>internal exposition is provided by HGitaly in some cases, e.g,
branch resolution, and Gitaly in other cases, e.g., file contents
and directory listing.</li>
</ul>
<p>In other words, Mercurial native projects aren't really native
yet (as of Heptapod 0.20) from an internal point of view, but as far
as persistent data and user experience are concerned, they actually are.
Also, newly created native projects shouldn't need to
undergo heavy data migration in the future.</p>
<p>We will naturally need heavy migrations and fallbacks for existing non-native
Mercurial projects. These are also under development. The tracking
issues are <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/issues/420">heptapod#420</a> and <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/issues/421">heptapod#421</a>.</p>
<p>Today, all newly created Mercurial projects of <a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a>
are native.</p>
</div>
<div class="section" id="hgitaly2-fully-native-mode">
<span id="fully-native"></span><h2>HGitaly2: fully native mode</h2>
<p>Since we started to ship HGitaly1 and let users create native
projects, we've been working on the next step: having all Mercurial
content been served through HGitaly, which will lead us eventually to
drop the conversion to Git entirely.</p>
<p>This is a bit trickier than what we did for <a class="reference external" href="https://foss.heptapod.net/groups/heptapod/-/milestones/43">HGitaly1</a>, which was
mostly reimplementing in <a class="reference external" href="https://foss.heptapod.net/heptapod/hgitaly">HGitaly</a> the conventional branch mappings
we already were doing in the conversion to Git.</p>
<p>Indeed, the Gitaly protocol is, perhaps unsurprisingly, Git centric in
that it expects to address directory and file contents in terms of Git
object ids. So we needed to find our way around that. It was one of
the motivations for the split in the <a class="reference external" href="https://foss.heptapod.net/groups/heptapod/-/milestones/43">HGitaly1</a> and <a class="reference external" href="https://foss.heptapod.net/groups/heptapod/-/milestones/44">HGitaly2</a>
milestones, the other one being the coincidence with user goodness and
data migration properties provided by <a class="reference external" href="https://foss.heptapod.net/groups/heptapod/-/milestones/43">HGitaly1</a>.</p>
<p>The good news is that we now have prototype implementations for all
the needed Gitaly calls: a few days ago, a development instance passed
for the first time all the <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod-tests">functional tests</a> in fully native mode.
This was a look ahead attempt that combined all the current experimental code,
to gather insights and help us decide on a release plan.</p>
</div>
<div class="section" id="release-plan-1">
<span id="release-plan"></span><h2>Release plan</h2>
<p>In Heptapod 0.19 and 0.20, native Mercurial projects are operating at the
HGitaly1 level. This means that they won't need any data migration to
work with the future fully native mode.</p>
<p>Even better, as long
as we keep converting to Git behind the scenes, we can switch back and
forth between the fully native mode of HGitaly2, in which the
converted Git content is not actually used, and the current
partially native mode of HGitaly1. We will even be able to do that without
instance restarts.</p>
<p>Now we know that no matter the amount of automated testing, a piece of
software cannot achieve production readiness without extensive testing
by real users. So we will ship in several steps and provide our early
adopters with means to use the new modes without incurring much risk.</p>
<div class="section" id="step-1-feature-gating-and-transparent-fallbacks">
<h3>Step 1: feature gating and transparent fallbacks</h3>
<p>In a next release, we will introduce the fully native mode as a
development <a class="reference external" href="https://docs.gitlab.com/ce/development/feature_flags/">feature flag</a>, perhaps even at the Project or Group level.</p>
<p>On instances running with the feature activated,
all read operations on Mercurial native projects will then
involve Mercurial only, while writes will still be converted to Git
for easy fallback to the more mature HGitaly1. Non-native Mercurial
projects will be entirely unaffected.</p>
<p>We will of course activate the fully native mode on the Heptapod
instances that we manage ourselves, notably
<a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a>. After a while, we will encourage our closest
partners to do the same, and provide them support in return.</p>
<p>This could happen as soon as in Heptapod 0.21, but we won't hesitate
to postpone to 0.22, because of the also appealing goal of releasing
0.21 at about the same time as GitLab 13.10, which is scheduled for
March 22nd.</p>
</div>
<div class="section" id="step-2-unplug-the-conversion-to-git">
<h3>Step 2: unplug the conversion to Git</h3>
<p>At this point, instances running with the fully native feature flag
will stop converting new content to Git for native Mercurial
projects.</p>
<p>Fallbacking to the
partially native mode will then
involve bringing back the auxiliary Git repository on par with the
Mercurial repository. We will provide a way to do that, probably as a
Rake task.</p>
<p>Some of our users
are actually taking advantage of the Git conversion to
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/issues/125">mirror their repositories to Git-centric external systems</a>. We
consider that an interesting feature, even if it happened
without planning on our side.
Hence this will be the time to properly support it.</p>
<p>Since the conversion to Git is a major performance bottleneck for
large repositories, this step will allow us to conduct experiments to
assess what Heptapod can handle. We are currently hosting a couple
repositories with about 100 000 changesets (<a class="reference external" href="https://foss.heptapod.net/pypy/pypy">PyPy</a> and <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod">Heptapod
itself</a>), and have been considering this
order of magnitude to be the biggest reasonable one. At this step, we
will be able to test repositories in the ballpark of a million changesets.</p>
</div>
<div class="section" id="step-3-fully-native-by-default">
<h3>Step 3: fully native by default</h3>
<p>This is just changing the default value of the feature flag. At this
point, an explicit configuration will be needed for native Mercurial
projects to run in partially native mode.</p>
<p>If you've been following so far, you know that the type of new
Mercurial projects (native of not) is completely orthogonal to the
fully native mode of operation. Nevertheless, if all new
Mercurial projects are already native by default by the time we reach
this step, we can (and should!) label it Heptapod 1.0.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">depending on how testing at Step 1 goes, we may actually
decide to perform Step 3 before Step 2. But we'll still need
both to claim the 1.0 milestone.</p>
</div>
<!-- edit 2023-12-04:: we have reached this step with Heptapod 0.40:
the conversion to Git is disabled by default, but
is still controlled by feature flags. If all goes
well, We will remove the latter in Heptapod 0.41. -->
</div>
</div>
<div class="section" id="in-conclusion">
<h2>In conclusion</h2>
<p>Thank you for reading this long article, we hope you enjoyed it.</p>
<p>We have pretty exciting times ahead, looking forward to Heptapod 1.0,
with fully native Mercurial projects. It seems we can be there by the
summer.</p>
</div>
Heptapod 0.20 pre-release2021-02-22T00:00:00+01:002021-02-22T00:00:00+01:00Georges Racinettag:heptapod.net,2021-02-22:/heptapod-020-pre-release.html<p>Heptapod 0.20.0rc1 was released today,
featuring GitLab 13.9 and aiming for a final version on March 2nd.
Many thanks to all our contributors, of any kind. Please give it a
try, and tell us about it!</p>
<p>The release candidate was installed shortly afterwards on
<a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net …</a></p><p>Heptapod 0.20.0rc1 was released today,
featuring GitLab 13.9 and aiming for a final version on March 2nd.
Many thanks to all our contributors, of any kind. Please give it a
try, and tell us about it!</p>
<p>The release candidate was installed shortly afterwards on
<a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a>.</p>
<p>Heptapod 0.20.0rc1 can be installed as a
<a class="reference external" href="https://hub.docker.com/r/octobus/heptapod/tags?page=1&name=0.20.0rc1&ordering=last_updated">Docker image</a>
and
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/heptapod-0.20.0rc1/INSTALL_HEPTAPOD.md">from source</a>
(don't miss the new Workhorse instructions).</p>
<p>The full changelog is available as usual <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/branch/heptapod-0-20/HEPTAPOD_CHANGELOG.md">alongside the sources</a>.</p>
<div class="section" id="short-term-release-schedule-and-installations">
<h2>Short term release schedule and installations</h2>
<p>For the first time, we're releasing the Heptapod release candidate the
same day that upstream GitLab release their x.y.0 version. An
immediate benefit of this for our users is that the previous Heptapod
0.19 version will stay supported a few weeks instead of a few days.</p>
<p>The RC phase will end on March 2nd, with the final release of
Heptapod 0.20.0 and immediate installation on the flagship platforms:
<a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a> and <a class="reference external" href="https://about.heptapod.host">heptapod.host</a>. The former will run the
release candidate until then.</p>
<p>GitLab 13.7 and thus Heptapod 0.19 will their end of life on March 22nd.</p>
</div>
<div class="section" id="major-changes">
<h2>Major changes</h2>
<div class="section" id="workhorse">
<h3>Workhorse</h3>
<p>Heptapod Workhorse sources do not live in a separate repository
anymore, but in the <tt class="docutils literal">workhorse/</tt> subdirectory of the main repository.</p>
<p>This has no impact for users of the Docker image or the Omnibus packages.</p>
<p>Upstream has been preparing this for months, with a gradual transition
plan that is now nearly complete. Heptapod having fewer
build and deployment options, we wanted to spare us such an
effort. This was actually the primary motivation to jump directly on
GitLab 13.9, a version fully ready for the bundled Workhorse, thus
skipping 13.8.</p>
<p>The install documentation has been updated to reflect the change, the
short summary for new installations being that applying upstream
GitLab procedure (Rake task) just works.</p>
<p>For more details and pointers to upstream information, see our
tracking issue, <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/issues/402">heptapod#402</a>.</p>
</div>
<div class="section" id="docker-image-and-omnibus-package">
<h3>Docker image and Omnibus package</h3>
<p>Our Docker image makes a big leap, being now based on Ubuntu 20.04
instead of Ubuntu 16.04. Most users shouldn't notice any difference.</p>
<p>This also follows an
<a class="reference external" href="https://gitlab.com/groups/gitlab-org/-/epics/5109">upstream GitLab move</a>),
due to the EOL of Ubuntu 16.04 in April 2021.</p>
<p>We are still building only the variant for the Docker image. Nothing
changed for Heptapod 0.19 Omnibus builds. To summarize, here are the
Omnibus packages that we are currently producing:</p>
<ul class="simple">
<li>Heptapod 0.19: Ubuntu 16.04 (xenial)</li>
<li>Heptapod 0.20: Ubuntu 20.04 (focal)</li>
</ul>
<p>These packages aren't widely distributed yet. Also, nothing prevents us
to build for other targets (Debian stable would be an easy one).
Don't hesitate to <a class="reference external" href="/pages/contact-us.html#contact-us">contact us</a> if you are interested.</p>
</div>
</div>
<div class="section" id="next-development-highlights">
<h2>Next development highlights</h2>
<p>Heptapod 0.19 will keep on receiving bugfixes and low risk features
until March 22nd.</p>
<div class="section" id="heptapod-runner">
<h3>Heptapod Runner</h3>
<p>The effort announced with Heptapod 0.19 is still ongoing, partly
because we moved faster towards Heptapod 0.20 than expected a month
ago.</p>
</div>
<div class="section" id="mercurial-native-mode">
<h3>Mercurial native mode</h3>
<p>All newly created Mercurial projects on <a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a> are
native. Currently, that only means that their commit hashes are
native, but that makes the most difference for users.
More details are available on the <a class="reference external" href="https://foss.heptapod.net/groups/heptapod/-/milestones/43">HGitaly1</a> milestone.</p>
<p>Progress towards the <a class="reference external" href="https://foss.heptapod.net/groups/heptapod/-/milestones/44">HGitaly2</a> milestone:</p>
<ul class="simple">
<li>The processing of new changesets for messaging to the Rails
application is now ready to work without a Git repository.</li>
<li>Experiments to expose changeset content
through HGitaly are roughly halfway through. These are manifests and
files in Mercurial terminology, trees and blobs in Git(aly)
terminology. This is where the most risk lies, due to the Git-centric
identifiers used by the Gitaly protocol</li>
<li>Good progress has been made also in the exposition of diffs, for
which the protocol translates more directly in Mercurial terms than
for trees and blobs</li>
<li>Work has started on migration tasks and other transition helpers,
see the <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/issues/420">heptapod#420</a> and <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/issues/421">heptapod#421</a> tracking issues.</li>
</ul>
</div>
</div>
<div class="section" id="in-conclusion">
<h2>In conclusion</h2>
<p>We're delighted to give our users more time to upgrade before the end
of life of the current stable series, Heptapod 0.19.</p>
<p>We would be very happy to release the next version so shortly after
GitLab 13.10, but this would be but one goal among many. We'll
certainly try if we have the resources.</p>
<p>Thank you for reading so far, and again, many
thanks to all the people that contributed to this release, be it by funding,
submitting code, documentation, or simply user feedback.</p>
</div>
Heptapod 0.19 and what's next2021-01-18T00:00:00+01:002021-01-18T00:00:00+01:00Georges Racinettag:heptapod.net,2021-01-18:/heptapod-019-and-whats-next.html<p>Heptapod 0.19.0rc2 was released today,
featuring GitLab 13.7. The final version will be released on January
20th. Many thanks to all our contributors, of any kind.</p>
<p>The release candidate was installed immediately on
<a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a>.</p>
<p>Heptapod 0.19.0rc2 can be installed as a
<a class="reference external" href="https://hub.docker.com/r/octobus/heptapod/tags?page=1&name=0.19.0rc2&ordering=last_updated">Docker image …</a></p><p>Heptapod 0.19.0rc2 was released today,
featuring GitLab 13.7. The final version will be released on January
20th. Many thanks to all our contributors, of any kind.</p>
<p>The release candidate was installed immediately on
<a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a>.</p>
<p>Heptapod 0.19.0rc2 can be installed as a
<a class="reference external" href="https://hub.docker.com/r/octobus/heptapod/tags?page=1&name=0.19.0rc2&ordering=last_updated">Docker image</a>
and
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/heptapod-0.19.0rc2/INSTALL_HEPTAPOD.md">from source</a>.</p>
<p>The full changelog is available as usual <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/branch/heptapod-0-19/HEPTAPOD_CHANGELOG.md">alongside the sources</a>.</p>
<div class="section" id="short-term-schedule-for-release-and-installations">
<h2>Short term schedule for release and installations</h2>
<p>The RC phase will end on January 20th, with the final release of
Heptapod 0.19.0 and immediate installation on the flagship platforms:
<a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a> and <a class="reference external" href="https://about.heptapod.host">heptapod.host</a>.</p>
<p>GitLab 13.5 and thus Heptapod 0.18 will reach end of life on January 22nd.</p>
</div>
<div class="section" id="major-changes">
<h2>Major changes</h2>
<p>Heptapod 0.19 is at the foremost a consolidation version. Its main
focus was the upstream upgrade, which this time got us jumping directly
from 13.5 to 13.7. This move buys us back some flexibility in
development scheduling, as GitLab 13.7 should reach its end of life on
March 22nd.</p>
<p>Under the hood, significant improvements occurred in our development
and release process, with our continous integration now running a much
larger part of the upstream tests. We're leveraging for this the
resources provided by the <a class="reference external" href="https://startup.ovhcloud.com">OVHcloud Startup Program</a>, which we joined in
December.</p>
<p>Thanks to this, we are close to claiming full support for Git projects,
in other words, to stop calling it a "technology preview".</p>
<p>Mercurial native projects support is also improving: we are close to reaching
the <a class="reference external" href="https://foss.heptapod.net/groups/heptapod/-/milestones/43">HGitaly1</a> milestone. Whilst Mercurial native projects are still
themselves experimental, it can be considered safe to have some of
them on production servers.</p>
</div>
<div class="section" id="next-development-highlights">
<h2>Next development highlights</h2>
<p>Here are the area in which we'll be working in the next month or so:</p>
<div class="section" id="heptapod-runner">
<h3>Heptapod Runner</h3>
<p>A significant effort will be made for Heptapod Runner.</p>
<p>We'd like to</p>
<ul class="simple">
<li>Extend the list of supported platforms, adding notably Windows.
We currently have Linux for amd64 and arm64.</li>
<li>Boost the upstream version.</li>
<li>Explore auto-scaling runners options for <a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a> and
<a class="reference external" href="https://about.heptapod.host">heptapod.host</a>.</li>
</ul>
</div>
<div class="section" id="mercurial-native-mode">
<h3>Mercurial native mode</h3>
<p>We will be starting exploration of the <a class="reference external" href="https://foss.heptapod.net/groups/heptapod/-/milestones/44">HGitaly2</a> milestone right
after the final Heptapod 0.19.0 release:</p>
<ul class="simple">
<li>Experiments for the fully native mode.</li>
<li>First migration tasks and other transition helpers.</li>
</ul>
</div>
</div>
<div class="section" id="in-conclusion">
<h2>In conclusion</h2>
<p>This has been a busy start of year, and we now have exciting
perspective ahead.</p>
<p>Thanks for reading so far, we wish you a safe and productive new year.</p>
</div>
Heptapod 0.18.0 released, featuring GitLab 13.5 and Rust options2020-12-21T00:00:00+01:002020-12-21T00:00:00+01:00Octobustag:heptapod.net,2020-12-21:/heptapod-0.18.0.html<p>We're especially happy to announce the final release of Heptapod
0.18.0, based on GitLab 13.5 (security updates until
January 22th, 2021).</p>
<p>Many thanks to all the people that contributed to this release.</p>
<p>Heptapod 0.18.0 can be installed as a
<a class="reference external" href="https://hub.docker.com/r/octobus/heptapod/tags?page=1&name=0.18.0&ordering=last_updated">Docker image</a>
and
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/heptapod-0.18.0/INSTALL_HEPTAPOD.md">from source</a>.</p>
<p>The …</p><p>We're especially happy to announce the final release of Heptapod
0.18.0, based on GitLab 13.5 (security updates until
January 22th, 2021).</p>
<p>Many thanks to all the people that contributed to this release.</p>
<p>Heptapod 0.18.0 can be installed as a
<a class="reference external" href="https://hub.docker.com/r/octobus/heptapod/tags?page=1&name=0.18.0&ordering=last_updated">Docker image</a>
and
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/heptapod-0.18.0/INSTALL_HEPTAPOD.md">from source</a>.</p>
<p>The full changelog is available as usual <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/heptapod-0.18.0/HEPTAPOD_CHANGELOG.md#heptapod-0180-2010-12-21">alongside the sources</a>.
It has a summary of changes from the last Heptapod 0.17 version and a
separate section for changes since 0.18.0rc2.</p>
<p>This is the last 0.x.0 version of this year, we'll proceed with the
upcoming 0.19 in January 2021.</p>
<div class="section" id="progress-done-in-the-heptapod-0-18-development-cycle">
<h2>Progress done in the Heptapod 0.18 development cycle</h2>
<p>We bumped GitLab to 13.5 and Mercurial to 5.6.</p>
<p>Lots of the work that has been done during that cycle falls in the
development infrastructure category: we are now ready for larger scale
testing and continuous integration, especially for the HGitaly component, which
lies at the heart of the implementation of Mercurial native projects.</p>
</div>
<div class="section" id="state-of-the-technology-previews">
<h2>State of the technology previews</h2>
<ul class="simple">
<li><em>New in 0.18</em> Rust-enhanced Mercurial: available in Omnibus/Docker packaging,
needs to be explicitely activated. Many more details in the
<a class="reference external" href="/heptapod-0180rc2-released-with-rust-in-mercurial.html#heptapod-0180rc2-released-with-rust-in-mercurial">Heptapod 0.18.0rc2</a> release notes.</li>
<li>Git repositories: we haven't heard of serious problems so far, but
we'll need more feedback to declare this fully working.</li>
<li>Native Mercurial repositories: general robustness and performance
improvements. The first round of implementation is almost done,
we're readying ourselves to the next one.</li>
<li>Omnibus deployments: no change since Heptapod 0.17; no user feedback
about use outside of Docker containers (the Docker image is just a
preinstalled Omnibus package).</li>
</ul>
</div>
<div class="section" id="what-lies-ahead-in-early-2021">
<h2>What lies ahead in early 2021</h2>
<p>We're planning to increase the CI/CD capabilities in an effort related
to the recent admission of the Heptapod project in the OVHcloud startup program.</p>
<p>We'll jump to GitLab 13.7 as soon as possible, to get back a safety
margin for Heptapod specific developments.</p>
<p>Mercurial native projects will keep being a strong focus of ours. The
first experiments related to the <a class="reference external" href="https://foss.heptapod.net/groups/heptapod/-/milestones/44">HGitaly2</a> milestone should start as
soon as January.</p>
</div>
Heptapod 0.18.0rc2 released, with Rust in Mercurial2020-12-15T00:00:00+01:002020-12-15T00:00:00+01:00Georges Racinettag:heptapod.net,2020-12-15:/heptapod-0180rc2-released-with-rust-in-mercurial.html<p>We're very glad to announce the release of Heptapod 0.18.0rc,
featuring GitLab 13.5 and Mercurial 5.6.1 built with Rust. Thanks to
all those that helped during this development cycle.</p>
<p>It is specially heartening to see Heptapod and the Rust reimplementation of
some parts of Mercurial …</p><p>We're very glad to announce the release of Heptapod 0.18.0rc,
featuring GitLab 13.5 and Mercurial 5.6.1 built with Rust. Thanks to
all those that helped during this development cycle.</p>
<p>It is specially heartening to see Heptapod and the Rust reimplementation of
some parts of Mercurial, two major development efforts
led by Octobus, be finally joined together. The Rust parts have to be
explicitely activated, see below for more details.</p>
<p>The release candidate was installed on December 14th on
<a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a> and is running the Rust code at the moment of
this writing.</p>
<p>Heptapod 0.18.0rc2 can be installed as a
<a class="reference external" href="https://hub.docker.com/r/octobus/heptapod/tags?page=1&name=0.18.0&ordering=last_updated">Docker image</a>
and
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/heptapod-0.18.0rc2/INSTALL_HEPTAPOD.md">from source</a>.</p>
<p>The full changelog is available as usual <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/branch/heptapod-0-18/HEPTAPOD_CHANGELOG.md">alongside the sources</a>.</p>
<div class="section" id="short-term-schedule-for-release-and-installations">
<h2>Short term schedule for release and installations</h2>
<p>The RC phase will end on December 21st, with the final release of
Heptapod 0.18.0 and immediate installation on the flagship platforms:
<a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a> and <a class="reference external" href="https://about.heptapod.host">heptapod.host</a>.</p>
<p>Meanwhile, <a class="reference external" href="https://about.heptapod.host">heptapod.host</a>
will get its last 0.17 update on December 16th with the installation
of the 0.17.3 to be soon released.</p>
<p>GitLab 13.4 and thus Heptapod 0.17 will reach end of life on December 22nd.</p>
</div>
<div class="section" id="rust-enhanced-mercurial-in-heptapod">
<span id="rust"></span><h2>Rust-enhanced Mercurial in Heptapod</h2>
<p>Since the end of 2018, alternative implementations of Mercurial
internals in the Rust programming language have been under
development, with drastic performance improvements being the obvious
goal.</p>
<p>Starting with version 0.18.0rc2, Mercurial enhanced with Rust is
an option in Heptapod that has to be explicitely activated.</p>
<div class="section" id="activating-rust-parts-of-mercurial-in-binary-distributions">
<h3>Activating Rust parts of Mercurial in binary distributions</h3>
<p>Binary distributions
Omnibus packages and Docker images will ship Mercurial compiled with
Rust, but the Rust parts are left disabled by default.
To activate Rust, add this to <cite>/etc/gitlab/gitlab.rb</cite> or the ``
environment variable of a Docker container:</p>
<pre class="literal-block">
mercurial['invocation']['module_policy'] = "rust+c"
</pre>
<p>This requires a container restart or a call to <cite>gitlab-ctl reconfigure</cite>.</p>
<p>For the record, the default "policy" is "c", but the simplest way to
get back to the default behaviour is to comment out this policy
setting.</p>
</div>
<div class="section" id="activating-rust-parts-of-mercurial-in-source-installations">
<h3>Activating Rust parts of Mercurial in source installations</h3>
<p>There is a <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/heptapod-0.18.0rc2/INSTALL_HEPTAPOD.md#variant-mercurial-enhanced-with-rust">Rust variant of the install procedure</a>. It
boils down to using a different Python requirements file.</p>
<p>Once that is done, the Rust parts of Mercurial are enabled by
default and can be disabled at any time, by changing the "module policy"
in four different configuration files.</p>
</div>
<div class="section" id="expected-performance-improvements">
<h3>Expected performance improvements</h3>
<p>This is a first step in which we don't expect performance improvements
to be very visible yet, but please try it early and report back. This
will certainly help us moving forward to reap the expected benefits
down the road.</p>
<p>Right now, we can expect some algorithms about the graph of changesets
to become faster, but they don't amount for a significant portion of
the time spent, and are often running in background jobs anyway.</p>
<p>Basically, we're doing this now so that we will be ready when it will start to
matter, for example in the handling of large repositories once other
bottlenecks are removed. The conversion to Git
that we are also actively working on removing is a prime example of such
bottlenecks.</p>
<p>The most significative performance improvement will come with the
activation of the persistent nodemap with Rust
implementation. We'll probably include this in the next Heptapod
release. This persistent nodemap eliminates a source of
server-side latency in push/pull operations for large repositories
(for all Mercurial servers) and
also in the rendering of cross-references to changesets (specifically for
native Mercurial repositories in Heptapod). This illustrates in
particular how diverse the impacts of such low-level improvements can
be. We can expect the change to be felt with repositories around 100
000 changesets, such as PyPy and Heptapod (Rails).</p>
<p>Of course Rust is an active development area in Mercurial, meaning
that future versions can provide us with more visible
improvements that we'll be glad to leverage immediately.</p>
</div>
</div>
Heptapod 0.17.0 released, featuring GitLab 13.4 and Git projects2020-11-20T00:00:00+01:002020-11-20T00:00:00+01:00Octobustag:heptapod.net,2020-11-20:/heptapod-0.17.0.html<p>We're glad to announce the final release of Heptapod
0.17.0, based on GitLab 13.4 (security updates until
December 22th, 2020), with 3 technology previews, including Git
support.</p>
<p>Heads up: all projects get migrated to the <a class="reference external" href="https://docs.gitlab.com/ce/administration/repository_storage_types.html">hashed storage</a>.
Major changes in installation from source, see
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/branch/heptapod/INSTALL_HEPTAPOD.md">INSTALL_HEPTAPOD</a>.</p>
<p>Many thanks …</p><p>We're glad to announce the final release of Heptapod
0.17.0, based on GitLab 13.4 (security updates until
December 22th, 2020), with 3 technology previews, including Git
support.</p>
<p>Heads up: all projects get migrated to the <a class="reference external" href="https://docs.gitlab.com/ce/administration/repository_storage_types.html">hashed storage</a>.
Major changes in installation from source, see
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/branch/heptapod/INSTALL_HEPTAPOD.md">INSTALL_HEPTAPOD</a>.</p>
<p>Many thanks to all the people that contributed to this release.</p>
<p>Heptapod 0.17.0 can be installed as a
<a class="reference external" href="https://hub.docker.com/r/octobus/heptapod/tags?page=1&name=0.17.0&ordering=last_updated">Docker image</a>
and
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/heptapod-0.17.0/INSTALL_HEPTAPOD.md">from source</a>.</p>
<p>The full changelog is available as usual <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/heptapod-0.17.0/HEPTAPOD_CHANGELOG.md">alongside the sources</a>. It
has a separate section for changes since Heptapod 0.17.0rc1.</p>
<div class="section" id="summary-of-technology-previews">
<h2>Summary of technology previews</h2>
<p>Many more details, including screenshots, are provided in the
<a class="reference external" href="/heptapod-0170rc1-released-with-3-tech-previews.html#heptapod-0170rc1-released-with-3-tech-previews">0.17.0rc1 announcement</a>.</p>
<ul class="simple">
<li>Git projects: the feature is still too fresh and not enough tested to
be declared ready for production. User feedback will be important here,
as we don't use Git a lot. Don't hesitate to <a class="reference external" href="/pages/contact-us.html">tell us about it</a></li>
<li>Mercurial native projects: still very incomplete, but we reached an
important milestone. We may elaborate more on them in a forthcoming
developer blog post.
You are welcome to activate the feature on <em>testing servers</em> only.
Do not put any such native project on a production
installation unless you are a knowledgeable developer of Heptapod.</li>
<li>Omnibus deployments: Debian packages for Ubuntu 16.04 are
available, tested in Docker context only. Please contact us if you want to
know more about them and help us validate them for general use.</li>
</ul>
<p>Happy heptapoding!</p>
</div>
Heptapod 0.17.0rc1 released with 3 tech previews2020-11-09T00:00:00+01:002020-11-09T00:00:00+01:00Georges Racinettag:heptapod.net,2020-11-09:/heptapod-0170rc1-released-with-3-tech-previews.html<p>Another exciting development cycle is coming to an end with the release of
Heptapod 0.17.0rc1 today, featuring GitLab 13.4 and three different
technology previews. Many thanks to our contributors!</p>
<p>Heads up: all projects get migrated to the <a class="reference external" href="https://docs.gitlab.com/ce/administration/repository_storage_types.html">hashed storage</a>.
Major changes in installation from source, see
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/branch/heptapod/INSTALL_HEPTAPOD.md">INSTALL_HEPTAPOD …</a></p><p>Another exciting development cycle is coming to an end with the release of
Heptapod 0.17.0rc1 today, featuring GitLab 13.4 and three different
technology previews. Many thanks to our contributors!</p>
<p>Heads up: all projects get migrated to the <a class="reference external" href="https://docs.gitlab.com/ce/administration/repository_storage_types.html">hashed storage</a>.
Major changes in installation from source, see
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/blob/branch/heptapod/INSTALL_HEPTAPOD.md">INSTALL_HEPTAPOD</a>.</p>
<p>A lot of progress was made in the
<a class="reference external" href="#build_packaging">build and packaging</a> department.
There is in particular:</p>
<ul class="simple">
<li>a new service: <tt class="docutils literal">hgitaly</tt></li>
<li>a new <a class="reference external" href="#versions">version numbers policy</a> for Heptapod components.</li>
</ul>
<p>We'll have no less than three different technology previews in
Heptapod 0.17: <a class="reference external" href="#git">Git projects</a>, <a class="reference external" href="#hg_native">Mercurial native</a>
projects and <a class="reference external" href="#omnibus">Omnibus</a> deployments.</p>
<div class="section" id="build-and-packaging-1">
<span id="build-packaging"></span><h2>Build and Packaging</h2>
<div class="section" id="omnibus-and-docker">
<h3>Omnibus and Docker</h3>
<p>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
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/issues/338">heptapod#338</a>), we were still building the final Docker image as a
modification on top of that.</p>
<p>In the 0.17 cycle, we followed up on that initial effort, to the point
where the final Docker image <em>is</em> 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</p>
<ul>
<li><p class="first">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.</p>
<p>We are
currently looking at options for proper distribution of the Omnibus
Debian package. Meanwhile, please <a class="reference external" href="/pages/contact-us.html">contact us</a>
directly if you want to give it a try. Also don't hesitate to
tell us if you're interested in other Linux distributions.</p>
</li>
<li><p class="first">the configuration of Heptapod specific services (<tt class="docutils literal"><span class="pre">hg-inner-http</span></tt> and
<tt class="docutils literal">hgitaly</tt>) can be managed like other GitLab services, with
<tt class="docutils literal">/etc/gitlab/gitlab.rb</tt> or Docker environment variables and
<tt class="docutils literal"><span class="pre">gitlab-ctl</span> reconfigure</tt></p>
</li>
<li><p class="first">our final Docker image is smaller by almost 200MB (uncompressed).</p>
</li>
<li><p class="first">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.</p>
</li>
</ul>
</div>
<div class="section" id="version-numbers-policy-for-components">
<span id="versions"></span><h3>Version numbers policy for components</h3>
<p>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.</p>
<p>This will save us lots of time, meaning we'll have more for features
and bug fixes.</p>
<p>See <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/issues/352">heptapod#352</a> for full details of the new version policy.</p>
</div>
</div>
<div class="section" id="git-support">
<span id="git"></span><h2>Git support</h2>
<p>That will be the second technology preview in Heptapod 0.17.0:</p>
<div class="figure">
<img alt="New project page, showing the VCS type selector" class="screenshot" src="https://heptapod.net/images/new_project_vcs_type.png" />
<p class="caption">Users can now select a VCS type on the "New Project" page</p>
</div>
<div class="figure">
<img alt="Overview of a Git project, showing the VCS type" class="screenshot" src="https://heptapod.net/images/git_project_vcs_type.png" />
<p class="caption">Projects using a non-default VCS type now display it explicitely,
as shown on this Git project.</p>
</div>
<p>This was the second most wanted feature in our early user surveys, but
we knew it wasn't a low hanging fruit: the tumultuous youth
of Heptapod entailed lots of hacking away Git-specific code.</p>
<p>On January 14th, we added a new <tt class="docutils literal">vcs_type</tt> field to Projects in the
database schema, and since then, each refactoring, each conflict
happening while merging upstream has been an opportunity to introduce
conditionals based on that field.</p>
<p>Needless to say, we've also had lots of direct refactorings to
detangle the Mercurial and Git repository handling code. As a result,
there wasn't so much lacking in Heptapod 0.16 to reinstate Git
projects: some UI independence, explicit testing and subsequent
debugging.</p>
<p>Of course, this is all very fresh, and will need lots of testing to
get past the "technology preview" stage. This is what pre-release
versions are for, and we are actively counting on our user community
to give feedback.</p>
<p>There is a new application setting in the Administration area to
control admissible VCS types for new projects, with Git being allowed by
default. What do you think of that choice? Don't hesitate to voice your opinion!</p>
<div class="figure">
<img alt="New project page, showing the VCS type selector" class="screenshot" src="https://heptapod.net/images/app_setting_vcs_types.png" />
</div>
<p>In an expected, yet still very exciting way, this "multi VCS"
independence will also allow us to introduce incrementally the
Mercurial native mode (visible in the screenshot above), and that
brings us to our third foundational technology preview.</p>
</div>
<div class="section" id="mercurial-native-mode">
<span id="hg-native"></span><h2>Mercurial native mode</h2>
<p>Heptapod 0.17.0 will also have for the first time the option to create
a project in Mercurial native mode. That is our third technology
preview.</p>
<p>It is very experimental at this point, we expect many basic features
<em>not</em> to work. That's precisely why we are shipping it: to assess what
is further needed. People are very welcome to try, just brace
yourself, work on a testing server, and read below to get your
expectations right and about error reporting.</p>
<div class="section" id="refinements-on-the-hgitaly-plan">
<h3>Refinements on the HGitaly plan</h3>
<p>We've had steady progress in the <a class="reference external" href="https://foss.heptapod.net/heptapod/hgitaly">HGitaly</a> 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.</p>
<p>First, we've make the plan more concrete by laying down <a class="reference external" href="https://foss.heptapod.net/groups/heptapod/-/milestones?search_title=HGitaly">three
milestones</a>
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.</p>
<p>HGitaly will be shipped for the first time with Heptapod 0.17 and
unconditionally serve archive requests (<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/issues/204">heptapod#204</a>). Since this is quite
independent from the rest of the application, this will serve as a
general warm-up.</p>
</div>
<div class="section" id="user-exposition-of-the-mercurial-native-mode">
<h3>User exposition of the Mercurial native mode</h3>
<p>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.</p>
<p>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.</p>
<p>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.</p>
</div>
<div class="section" id="what-is-supposed-to-work-in-0-17-0rc1">
<h3>What is supposed to work in 0.17.0rc1</h3>
<ul class="simple">
<li>push and pull should be the same as for regular Mercurial projects</li>
<li>Mercurial commit hashes only, everywhere in the web application (UI
and API). This is the main goal of the <a class="reference external" href="https://foss.heptapod.net/groups/heptapod/-/milestones/43">HGitaly1</a> milestone.</li>
<li>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.</li>
<li>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 (<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/issues/364">heptapod#364</a>) for that, and expect it to be ready for the
final 0.17.0 release.</li>
</ul>
</div>
<div class="section" id="how-to-report-broken-pages-or-requests">
<h3>How to report broken pages or requests</h3>
<p>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.</p>
<p>The majority of problems are expected to be missing HGitaly method
implementations. They come with explicit logs in the Rails application:</p>
<pre class="literal-block">
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'
(...)
</pre>
<p>and in the Mercurial log:</p>
<pre class="literal-block">
[2020-11-09 11:11:58 +0100] [793335] [ERROR] [hgitaly.errors] Not implemented. Tracking issue: https://foss.heptapod.net/heptapod/hgitaly/-/issues/15
</pre>
<p>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.</p>
</div>
<div class="section" id="what-will-still-be-missing-in-the-final-0-17-0">
<h3>What will still be missing in the final 0.17.0</h3>
<ul class="simple">
<li>Migration scripts for existing (hg-git based) projects</li>
<li>We will still be using an auxiliary Git repository to present some
content. Removing this need will be the goal of the <a class="reference external" href="https://foss.heptapod.net/groups/heptapod/-/milestones/44">Hgitaly2</a> milestone.</li>
<li>Potentially everything that's not working in rc1 and we didn't had
time to fix before the final release.</li>
</ul>
</div>
</div>
<div class="section" id="in-conclusion">
<h2>In conclusion</h2>
<p>This has been again a very busy and exciting development cycle.</p>
<p>Many thanks to all the people that helped making this happen, be it
through code contributions or financial support. It is much
appreciated.</p>
</div>
Heptapod News, end of summer2020-09-04T00:00:00+02:002020-09-04T00:00:00+02:00Georges Racinettag:heptapod.net,2020-09-04:/heptapod-news-end-of-summer.html<p>Many things happened this summer since the end of the Bitbucket era
and the <a class="reference external" href="/heptapod-0.15.0.html">Heptapod 0.15.0 release</a>, so it's well
worth an account.</p>
<p>We'll begin with a recap of advances from
July on developer tools, then report on the first Heptapod sprint and
end with current progress towards …</p><p>Many things happened this summer since the end of the Bitbucket era
and the <a class="reference external" href="/heptapod-0.15.0.html">Heptapod 0.15.0 release</a>, so it's well
worth an account.</p>
<p>We'll begin with a recap of advances from
July on developer tools, then report on the first Heptapod sprint and
end with current progress towards the future Heptapod 0.16.0.</p>
<div class="section" id="building-a-development-community">
<h2>Building a development community</h2>
<p>This is more of a general trend than breaking news.</p>
<p>Before the summer, our main priority had to be catching up to
current GitLab versions. This meant we were on very fast moving
ground, making it especially hard to capitalize on development tools
and onboard new contributors.</p>
<p>With the <a class="reference external" href="/heptapod-0.14.0.html">Heptapod 0.14.0 release</a>, we were
finally close enough to upstream that it made sense to work on the
development setup and I could envision my personal priorities to
change, focusing more on foundational work and enabling other
contributors.</p>
<p>This led in July to the first publication of the Heptapod Development
Kit (<a class="reference external" href="/hdk.html">HDK</a>) and the organization of the first Heptapod sprint,
which was on July 31th, half a week before my vacation time and
just a day after the 0.15.0 release.</p>
</div>
<div class="section" id="first-heptapod-sprint-in-virtual">
<h2>First Heptapod sprint, in virtual</h2>
<div class="section" id="the-plan">
<h3>The plan</h3>
<p>My original idea was to focus on documentation and user feedback,
because I thought that it would be very useful and wouldn't require a
fully working developer setup. Also, these matters tend to be easy to
release quickly, being at the top of the dependency chain as they are.</p>
<p>The sprint was organized on a rather short notice (about 3 weeks) and
was of course to be held remotely, given the current pandemic
situation. So we called it a virtual sprint (vsprint for short) and
decided it would be a single day, centered on the European time zone.
After a poll, we settled for Friday, July 31th.</p>
</div>
<div class="section" id="how-it-went">
<h3>How it went</h3>
<p>It turned out a bit differently than I expected, and that's very fine!</p>
<p>First, the attendees were more motivated by working on the user feedback
than on the builtin documentation, with the main target of
replacing messages and instructions meant for Git with Mercurial ones.</p>
<p>Since Heptapod actually wants to support eventually <em>both</em> Git and
Mercurial, in many cases, the changes went a bit deeper than changing
string constants.</p>
<p>Second, Elouan and Sushil were strongly interested into setting up a full
HDK for themselves, which means they are now ready to contribute also
in more central areas of Heptapod.</p>
<p>Meanwhile, Antoine decided to work on the HAML templates directly in
the Docker image, which led to his writing a
<a class="reference external" href="/hacking-on-heptapod-templates.html">blog post</a> about how to do so
efficiently.</p>
<p>Raphaël already had a working HDK that allowed him to be productive
right away and to help the others.</p>
</div>
<div class="section" id="conclusion">
<h3>Conclusion</h3>
<p>Overall, the day wasn't very crowded, but that was a good start.</p>
<p>On the concrete site of things, we end up with a better user
experience, with many messages adapted for Mercurial in Heptapod
0.15.1, that was released a few days later.</p>
<p>To have two more fully equipped developers was a very good surprise,
and is very much in line with our goals of building a community.</p>
<p>I think we should definitely have more such vsprints, perhaps every
two months? That would place the next one at the end of September.</p>
</div>
</div>
<div class="section" id="the-future-heptapod-0-16">
<h2>The future Heptapod 0.16</h2>
<p>After I got back from vacation, I quickly declared Heptapod 0.15 to be
the new stable series (<a class="reference external" href="/hdk.html">HDK</a> users should upgrade),
and produced security update 0.15.2.</p>
<p>Then, development started again for the future 0.16 with some
foundational tasks. We are aiming at a release candidate next week.</p>
<div class="section" id="version-bumps-in-the-future-heptapod-0-16">
<h3>Version bumps in the future Heptapod 0.16</h3>
<p>Upstream GitLab was updated to 13.3, released on August 22nd.
Thanks to Heptapod 0.15.0 being
only one minor release behind upstream, we were for once not so much
in a hurry, but time flows fast anyway: GitLab 13.1 will reach its end
of life on September 22th.</p>
<p>Mercurial went from 5.4 to 5.5. There's not much to be said here,
except that of course that also required updating <tt class="docutils literal"><span class="pre">hg-evolve</span></tt> to
10.0.1 and <tt class="docutils literal"><span class="pre">hg-git</span></tt> to 0.9.0.</p>
</div>
<div class="section" id="solving-the-frontend-assets-packaging-issue">
<span id="omnibus"></span><h3>Solving the frontend assets packaging issue</h3>
<p>This is one of the two main pieces that we are currently missing
before we can tag Heptapod 1.0, the other being the
<a class="reference external" href="#hgitaly_advancement">Mercurial native mode</a>.</p>
<p>In short, we've never been able to ship modifications to GitLab's
front end, except for classical HAML templates. Suffice to say here
that there are many possible developments that are blocked because of
this. For more details, see <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/issues/338">heptapod#338</a>.</p>
<p>There's been good progress on that front, with early experiments
showing that the minimal approach outlined in <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/issues/338">heptapod#338</a> is the
way to go. This is also a logical step towards the long term goal of
providing fully operational Omnibus packages.</p>
</div>
<div class="section" id="mercurial-native-mode-1">
<span id="hgitaly-advancement"></span><h3>Mercurial native mode</h3>
<p>This is the long term subject to expose Mercurial changesets to GitLab
directly, instead of relying on an auxiliary Git repository. This
should be provided by integration of <a class="reference external" href="https://foss.heptapod.net/heptapod/hgitaly">HGitaly</a> project.</p>
<p>With all the version bumps, and the <a class="reference external" href="#omnibus">packaging overhaul</a>
taking priority, we didn't have much progress so far on that front
since the days of Heptapod 0.14. At this time, a fair amount of development
happened on the <a class="reference external" href="https://foss.heptapod.net/heptapod/hgitaly">HGitaly</a> project, but wasn't integrated.</p>
<p>We're currently about to resume work on integration of <a class="reference external" href="https://foss.heptapod.net/heptapod/hgitaly">HGitaly</a>
in Heptapod this week. That being said, it's probable that the actual
option will appear only after the Heptapod 0.16.0 release.</p>
</div>
</div>
Hacking On Heptapod Templates2020-07-31T00:00:00+02:002020-07-31T00:00:00+02:00Antoine Cezartag:heptapod.net,2020-07-31:/hacking-on-heptapod-templates.html<p>How to hack on Heptapod templates using docker-compose as ligthweight development environment</p><p>There are still a lot of places in the Heptapod user interface that need to be
adapted for Mercurial, and setting up a full development environment is not that easy
(it's not for GitLab either).</p>
<p>But there is a ligther way to contribue by editing the Rails templates using the
dockerized version.</p>
<p>First setup your mercurial to work with Heptapod as Heptapod uses Heptapod.</p>
<p>Install <a href="https://www.mercurial-scm.org/doc/evolution/">hg-evolve</a>
and activate some of its wonders by adding to your <code>~/.hgrc</code>:</p>
<div class="highlight"><pre><span></span><code><span class="k">[extensions]</span>
<span class="na">evolve</span><span class="w"> </span><span class="o">=</span>
<span class="na">topic</span><span class="w"> </span><span class="o">=</span>
</code></pre></div>
<p>More detailed instructions are available in the <a href="/pages/quick-start-guide.html#quick-start-guide">Merge Request Quick Start Guide</a>.</p>
<p>Then create and setup an account on
<a href="https://foss.heptapod.net">https://foss.heptapod.net</a>
to be able to contribute.</p>
<p>Get the code:</p>
<div class="highlight"><pre><span></span><code>hg clone https://foss.heptapod.net/heptapod/heptapod
cd heptapod
hg update heptapod
</code></pre></div>
<p>The Heptapod development happens in the <code>heptapod</code> branch, the <code>default</code> branch
being the bare GitLab version.</p>
<p>Add a <code>docker-compose.override.yaml</code>:</p>
<div class="highlight"><pre><span></span><code><span class="n">app</span><span class="o">:</span>
<span class="w"> </span><span class="n">image</span><span class="o">:</span><span class="w"> </span><span class="n">octobus</span><span class="o">/</span><span class="n">heptapod</span><span class="o">:</span><span class="n">latest</span>
<span class="w"> </span><span class="n">volumes</span><span class="o">:</span>
<span class="w"> </span><span class="o">-</span><span class="w"> </span><span class="o">./</span><span class="n">app</span><span class="sr">/views:/opt/gitlab/embedded/service/gitlab-rails/app/</span><span class="n">views</span>
<span class="w"> </span><span class="n">ports</span><span class="o">:</span>
<span class="w"> </span><span class="o">-</span><span class="w"> </span><span class="s2">"8080:80"</span>
<span class="w"> </span><span class="o">-</span><span class="w"> </span><span class="s2">"8022:22"</span>
<span class="w"> </span><span class="o">-</span><span class="w"> </span><span class="s2">"8443:443"</span>
</code></pre></div>
<p>Here we mount or local views in the docker container so our update are seen by
the running Rails application.</p>
<p>You're ready to hack:</p>
<div class="highlight"><pre><span></span><code>docker-compose up -d
</code></pre></div>
<p>From time to time, you may need to restart the Rails application:</p>
<div class="highlight"><pre><span></span><code><span class="nv">docker</span><span class="o">-</span><span class="nv">compose</span><span class="w"> </span><span class="k">exec</span><span class="w"> </span><span class="nv">app</span><span class="w"> </span><span class="nv">gitlab</span><span class="o">-</span><span class="nv">ctl</span><span class="w"> </span><span class="nv">restart</span><span class="w"> </span><span class="nv">puma</span>
</code></pre></div>
<p>When you have a modification to submit, request Developer access on the <a href="https://foss.heptapod.net/heptapod">Heptapod Group</a>:</p>
<p><img alt="Requesting access on the Heptapod group" src="https://heptapod.net/heptapod-request-access.png"></p>
<p>These are granted very liberally. Then follow the <a href="/pages/quick-start-guide.html#quick-start-guide">Merge Request Quick Start Guide</a>: commit in a topic,
push it, and submit your Merge Request.</p>Heptapod 0.15.0 released, featuring GitLab 13.12020-07-30T00:00:00+02:002020-07-30T00:00:00+02:00Octobustag:heptapod.net,2020-07-30:/heptapod-0.15.0.html<p>We're glad to announce the final release of Heptapod
0.15.0, based on GitLab 13.1, which should get security updates until
September 22th, 2020. This version makes also a nice ground for
further Heptapod development.</p>
<p>Many thanks to all the people involved!</p>
<p>This is a major GitLab version …</p><p>We're glad to announce the final release of Heptapod
0.15.0, based on GitLab 13.1, which should get security updates until
September 22th, 2020. This version makes also a nice ground for
further Heptapod development.</p>
<p>Many thanks to all the people involved!</p>
<p>This is a major GitLab version change: please
<strong>don't migrate directly from Heptapod<0.14</strong>. There are instructions
in the changelog to follow.</p>
<p>There is no change in Python version support in this release: Python 3
is the default, Python 2 is still supported.</p>
<p>Heptapod 0.15.0 can be installed as a
<a class="reference external" href="https://hub.docker.com/r/octobus/heptapod/tags?page=1&name=0.15.0&ordering=last_updated">Docker image</a>
and
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/blob/heptapod-0.15.0/INSTALL_HEPTAPOD.md">from source</a>.</p>
<p>The current Heptapod Runner 0.3 works with Heptapod 0.15. We'll make a
new version 0.4, based on GitLab Runner 13.1 with a release candidate
in the next few days.</p>
<p>The full changelog is available <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/blob/heptapod-0.15.0/HEPTAPOD_CHANGELOG.md">alongside the sources</a>.</p>
<p>These two last releases 0.14 and 0.15, have been mostly about climbing the upstream
versions ladder, and our policy dictates that we issue a new version
0.x.0 at least each time the upstream GitLab major or minor version (y.z) changes.
But we now have almost two months to focus on specific Heptapod
features, and we are in a good position for that – see <a class="reference external" href="#devtools">Development
tools improvements</a> below for more details.</p>
<div class="section" id="documentation-effort-for-0-15-1">
<h2>Documentation effort for 0.15.1</h2>
<p>Tomorrow (2020-07-31), we'll be hosting the first Heptapod virtual
sprint, focusing on documentation and user messages.</p>
<p>The meeting place is the <a class="reference external" href="https://mattermost.heptapod.net/heptapod/channels/development">Development channel of our Mattermost chat
system</a>.</p>
<p>We'll start at 11:00 UTC+2 with a
short discussion to define the goals and in particular how we'd like
Heptapod specific documentation to be organized for easy
discoverability. We'll end around 20:00 UTC+2.</p>
<p>People are naturally welcome to connect at any time and stay after the
end: we're well aware that time zones can make things complicated. If you want to
participate but can't make it at the beginning because it's 2 AM or 10
PM in your time zone, just chime in when you can. Also, if there's enough interested
contributors in time zones that are far from CET/CEST, we'll consider
making one of the next virtual sprints at a more suitable time to them.</p>
<p>It's possible that 0.15.1 may be released very soon afterwards, with
documentation changes only.</p>
</div>
<div class="section" id="security-updates">
<h2>Security updates</h2>
<p>In the previous <a class="reference external" href="heptapod-0.14.0.html">announcement for Heptapod 0.14.0</a> we were saying that we would start
applying security updates from upstream GitLab.</p>
<p>This happened in practice, with the release of Heptapod 0.14.1, whose
only change was to move from GitLab CE 12.10.11 to 12.10.14, the last
of the 12.10 versions.</p>
<p>We'll do our best in the future to follow upstream updates
as soon as possible (note that some of them involve the Enterprise
Edition only).
It's unlikely we'll make such a formal annoucement for each
intermediate release: a good way to stay posted is to follow us on our <a class="reference external" href="pages/contact.html">social
media channels</a>.</p>
</div>
<div class="section" id="development-tools-improvements-1">
<span id="devtools"></span><h2>Development tools improvements</h2>
<p>Some very important intermediate goals have been achieved while we
were working on Heptapod 0.15:</p>
<ul class="simple">
<li>we now have an official <a class="reference external" href="hdk.html">development kit</a></li>
<li>we layed down foundations for writing Heptapod integration tests in
the Web application and had our CI system run them</li>
<li>the HGitaly component is available in these integration tests. This
will be the cornerstone of its integration with the web application,
which is pretty much the long awaited native Mercurial mode.</li>
</ul>
<p>In other words, Heptapod is more ready than ever to welcome
contributions.</p>
<p>A separate blog post may provide more details about all of this.</p>
</div>
Heptapod Development Kit available2020-07-09T00:00:00+02:002020-07-09T00:00:00+02:00Octobustag:heptapod.net,2020-07-09:/hdk.html<p>Contributing to Heptapod has just become much easier, thanks to the
introduction of the <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod-development-kit">Heptapod Development Kit</a> (HDK).</p>
<p>Since the beginning of this year, we've been using a custom modified
version of the <a class="reference external" href="https://gitlab.com/gitlab-org/gitlab-development-kit">GitLab Development Kit</a> (GDK) for most Heptapod
development. However, it didn't go much beyond replacing <tt class="docutils literal">git</tt> by …</p><p>Contributing to Heptapod has just become much easier, thanks to the
introduction of the <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod-development-kit">Heptapod Development Kit</a> (HDK).</p>
<p>Since the beginning of this year, we've been using a custom modified
version of the <a class="reference external" href="https://gitlab.com/gitlab-org/gitlab-development-kit">GitLab Development Kit</a> (GDK) for most Heptapod
development. However, it didn't go much beyond replacing <tt class="docutils literal">git</tt> by
<tt class="docutils literal">hg</tt> to retrieve the source of the forked Heptapod components,
and it had never been published, living as a series of local
modifications to the GDK on personal setups.</p>
<p>This was obviously a great impediment for contributors, even though
some work could - and still can - be done directly with the Docker
images. With the HDK now being available, the barrier to entry for new
contributors is now way lower. Time to consider contributing to Heptapod!</p>
<p>We encourage all interested persons to reach out to us on our
<a class="reference external" href="https://matrix.to/#/#heptapod:matrix.org">communication channel</a>. We're eagerly awaiting your feedback!</p>
<div class="section" id="how-to-get-started">
<h2>How to get started?</h2>
<p>Come talk to us on our <a class="reference external" href="https://matrix.to/#/#heptapod:matrix.org">communication channel</a> and follow the instructions
in the <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod-development-kit/-/blob/branch/heptapod/README.md">README</a>.</p>
<p>While the HDK setup is only marginally heavier than the GDK's, it is
still a significant effort to perform for the first time – count at
least a few hours.
People already using the GDK should find it easy, though.</p>
</div>
<div class="section" id="is-the-hdk-mandatory-to-contribute-to-heptapod">
<h2>Is the HDK mandatory to contribute to Heptapod?</h2>
<p>No, it's not.</p>
<p>Even though the HDK makes it much, much easier, setting up a full
development rig is a serious investment that is not really needed in
some situations.</p>
<p>Let's not forget that not all contributions are code: all that one
needs to improve the builtin documentation, for example, is a <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/-/tree/branch/heptapod/doc">clone of
the sources</a>.
If one wants to see it rendered within the application, then
it's possible to apply the changes directly in the Docker image.</p>
<p>Changes in the templates and controllers of the Rails application can
also be done using the Docker image as a fully working preinstalled
environment, but the more one goes down in the layers (from
controllers to services to models to libraries), the more one should
consider using the HDK instead.</p>
<p>Finally some components are self-contained and self-tested enough to
be developed independently. For instance, <a class="reference external" href="https://foss.heptapod.net/heptapod/py-heptapod">py-heptapod</a> and <a class="reference external" href="https://foss.heptapod.net/heptapod/hgitaly">HGitaly</a> have comprehensive test
suites that allow to reproduce and fix bugs, or implement features if
enough specifications are available.</p>
</div>
<div class="section" id="what-does-the-heptapod-development-kit-do">
<h2>What does the Heptapod Development Kit do?</h2>
<p>The HDK has the same set of responsibilities than the GDK:</p>
<ul class="simple">
<li>clone all the source repositories, with consistent revisions</li>
<li>retrieve all the needed dependencies: hundreds of Ruby gems, Golang
libraries, Node.js packages and Python distributions</li>
<li>build everything</li>
<li>prepare development and testing databases</li>
<li>provide service management (<tt class="docutils literal">gdk start</tt> etc.)</li>
</ul>
<p>Here are the differences with the GDK:</p>
<ul class="simple">
<li>The relevant GitLab components are replaced by their Heptapod forks,
as Mercurial clones. The HDK automatically uses Mercurial shares for
quick bootstrap of new workspaces. This is especially useful to work
on several Heptapod series (e.g, <tt class="docutils literal">default</tt>, <tt class="docutils literal">stable</tt>…).</li>
<li>Additional Python components, including the target Mercurial version
are installed. This is done
in the <tt class="docutils literal">venv3</tt> and <tt class="docutils literal">venv2</tt> virtualenvs, with a <tt class="docutils literal">venv</tt>
symlink allowing to switch from Python 3 to Python 2 and back easily.</li>
<li>There's a specific <tt class="docutils literal"><span class="pre">hg-http</span></tt> service, currently running Gunicorn, as
in the source installation instructions. Soon, we'll have a
<tt class="docutils literal">hgitaly</tt> service as well.</li>
</ul>
<p>At this point, the forked components still bear their original GitLab
name, e.g. <tt class="docutils literal">gitlab/</tt> (Rails application), <tt class="docutils literal"><span class="pre">gitlab-workhorse/</span></tt> etc.
This might change in the future.</p>
</div>
Heptapod 0.14.0 released, featuring GitLab 12.102020-06-30T00:00:00+02:002020-06-30T00:00:00+02:00Octobustag:heptapod.net,2020-06-30:/heptapod-0.14.0.html<p>We're especially proud to announce the final release of Heptapod
0.14.0, catching up onto supported upstream GitLab versions.</p>
<p>Many thanks to all our contibutors, and especially for
those involved in user support on foss.heptapod.net – lots of
Bitbucket imports in the past few weeks!</p>
<p>Indeed, Heptapod 0 …</p><p>We're especially proud to announce the final release of Heptapod
0.14.0, catching up onto supported upstream GitLab versions.</p>
<p>Many thanks to all our contibutors, and especially for
those involved in user support on foss.heptapod.net – lots of
Bitbucket imports in the past few weeks!</p>
<p>Indeed, Heptapod 0.14.0 is based on GitLab 12.10.11, that should get
security updates until July 22th, 2020. We should now be able to
follow GitLab security updates with Heptapod point releases.</p>
<p>With Python 3 becoming the default in Heptapod 0.14, we have a fully
current software stack.</p>
<p>Heptapod 0.14.0 can be installed in Python 2 and Python 3 flavours as a
<a class="reference external" href="https://hub.docker.com/r/octobus/heptapod/tags?page=1&name=0.14.0">Docker image</a>
and
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/blob/heptapod-0.14.0/INSTALL_HEPTAPOD.md">from source</a>.</p>
<p>The current Heptapod Runner 0.2 can run jobs for Heptapod 0.14, but the natural
companion version will be Heptapod Runner 0.3, to be released tomorrow.</p>
<p>The full changelog is available <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/blob/heptapod-0.14.0/HEPTAPOD_CHANGELOG.md">alongside the sources</a>.
Like we've done before, it gives first a summary of the major changes
from 0.13.2, with details given in the entries for the successive
release candidates.</p>
<p>Actually, most of the work since Heptapod 0.14.0rc1 has
been about tightening bolts in the Bitbucket importer.</p>
<div class="section" id="other-benefits-of-being-on-current-upstream">
<h2>Other benefits of being on current upstream</h2>
<p>While security considerations are enough in themselves to justify the
catchup effort, there are many more sides to this achievement. Truly,
a new era opens up for Heptapod.</p>
<div class="section" id="being-closer-to-upstream-is-not-only-about-code">
<h3>Being closer to upstream is not only about code</h3>
<p>Many resources about a project in active development are more
consistent in the present than in the past. This applies to ongoing
issues, documentation, and even to the people themselves, as remembering
past knowledge scattered in many technical areas at a given point in
time is a challenge indeed. Of course, there are tools to overcome
that, e.g., VCS revisions and tags, changelogs, issue milestones,
versioned documentation, but this is still friction.</p>
<p>Overall, it will be much easier for us to engage with upstream,
now. Obviously, we are in a much better position to contribute to GitLab.</p>
<p>Some of the foundational tasks that are still ahead of us will become
simpler. Previously, we had to assess what GitLab had done in the two
years that we were lagging, plus where they are currently going and
ajust our plans accordingly, assuming that was even possible. All of
this took time, and we had to make some choices that we wouldn't have made
in other circumstances, especially if we knew that a proper solution
for a given problem would be obsoleted a few versions ahead.</p>
<p>All of this is much simpler now. The differences between Heptapod and
upstream GitLab will be easier to grasp for our users, the
documentation more easily relevant, and upstream issues easier to find.</p>
</div>
<div class="section" id="staying-current-will-now-be-easier">
<h3>Staying current will now be easier</h3>
<p>The sheer volume of upstream GitLab updates is staggering. For
instance, we measured almost 15 000 modified files between GitLab 12.3
and 12.10. Granted, most of that has nothing to do with the VCS
support, but it is still impressive.</p>
<p>In January 2020, about the time we launched foss.heptapod.net, Heptapod was
at version 0.8.0, based on GitLab 10.5.8 (2018-04-24), which itself a
stable update for GitLab 10.5 (first released on 2018-02-22).
With GitLab 12.1 released in April 2020, this means that we had to
adapt to <em>26 months of upstream development in 5.5 months</em>, all the
while taking care of existing instances and providing the corresponding
<a class="reference external" href="/heptapod-0120-rc-featuring-gitlab-12.html#migrate-0-12">exceptional data migrations</a>.</p>
<p>Speaking with data migrations, we will now be on the normal procedure:
users will have to spend at least a few days on Heptapod 0.14 (GitLab
12.10) before they proceed to Heptapod 0.15 (GitLab 13.x).</p>
<p>As far as the development goes, soon, we'll just need to adapt
Heptapod at the same pace as upstream GitLab produce versions. This
means in turn that more time can be dedicated to
features, development tools and documentation… and growing the community.</p>
<p>Why just "soon", and not "from now on"? We still have one last step to
climb: from GitLab 12.10 to 13.1 in three weeks. Since that is a major
version change, we can expect it to be bigger than just two monthly releases.</p>
</div>
</div>
Heptapod 0.14.0rc1 released, featuring GitLab 12.102020-06-22T00:00:00+02:002020-06-22T00:00:00+02:00Octobustag:heptapod.net,2020-06-22:/heptapod-0.14.0rc1.html<p>Heptapod is very close to reaching one of its few major goals: catching
up to a currently supported upstream GitLab version.</p>
<p>Today's release of Heptapod 0.14.0rc1 is based on GitLab 12.10, which will
get security fixes until July, 22th. We expect the final 0.14.0 to …</p><p>Heptapod is very close to reaching one of its few major goals: catching
up to a currently supported upstream GitLab version.</p>
<p>Today's release of Heptapod 0.14.0rc1 is based on GitLab 12.10, which will
get security fixes until July, 22th. We expect the final 0.14.0 to
appear in a matter of days.</p>
<p>Heptapod 0.14.0rc1 can be installed in Python 2 and Python 3 flavours as a
<a class="reference external" href="https://hub.docker.com/r/octobus/heptapod/tags?page=1&name=0.14.0rc1">Docker image</a>
and
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/blob/heptapod-0.14.0rc1/INSTALL_HEPTAPOD.md">from source</a>.</p>
<p>The full changelog is available <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/blob/heptapod-0.14.0rc1/HEPTAPOD_CHANGELOG.md">alongside the sources</a>.</p>
<div class="section" id="a-change-in-the-roadmap">
<h2>A change in the roadmap?</h2>
<p>Yes, but not really a change of plans.</p>
<p>Originally, two goals were stated for Heptapod 0.14 in our
<a class="reference external" href="/pages/roadmap.html">roadmap</a>: native Mercurial support and GitLab version bump, "ideally
landing on GitLab 12.10".</p>
<p>From a development point of view, starting with the
version bump was actually the natural thing to do, and of course we
tried GitLab 12.10 right away.</p>
<p>And it worked!</p>
<p>GitLab 12.10 was first released on April 22th. According to the
general <a class="reference external" href="https://docs.gitlab.com/ee/policy/maintenance.html">GitLab Release and Maintenance policy</a>, this means that it will get
general bug fixes until the release of GitLab 13.1 (scheduled for
this very day) and security fixes until GitLab 13.2, whose release
should happen on July 22th.</p>
<p>At the time the roadmap was written, we could not promise that
Heptapod 0.14 would be based on GitLab 12.10,
but once it was there, we felt that
it would make sense to reap the benefits right away and provide our
users with a supported GitLab version.</p>
<p>In other words, we're progressing as intended, and simply decided to
release earlier and relabel the milestones accordingly.</p>
</div>
<div class="section" id="what-s-happening-with-native-mercurial-support">
<h2>What's happening with native Mercurial support?</h2>
<p>The development of the HGitaly project, which will bring native
Mercurial support in Heptapod, is currently under way, with good
progress.</p>
<p>Instead of being called 0.14, the first version to rely on HGitaly for
exposition of Mercurial repository content will be 0.15.</p>
<p>It is possible that we start shipping HGitaly as a technology preview
in a forthcoming intermediate 0.14.x release. As such, it wouldn't be
activated by default, even for new projects.</p>
</div>
Heptapod 0.13.1 released2020-06-11T00:00:00+02:002020-06-11T00:00:00+02:00Octobustag:heptapod.net,2020-06-11:/heptapod-0.13.1.html<p>We're happy to announce the release of Heptapod 0.13.1.</p>
<p>This version brings in important internal changes that solve several
long standing issues, and features a new technology preview, in
preparation for Heptapod 0.14.</p>
<p>The full changelog is available as usual <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/blob/heptapod-0.13.1/HEPTAPOD_CHANGELOG.md">with the sources</a></p>
<p>Heptapod 0.13.1 …</p><p>We're happy to announce the release of Heptapod 0.13.1.</p>
<p>This version brings in important internal changes that solve several
long standing issues, and features a new technology preview, in
preparation for Heptapod 0.14.</p>
<p>The full changelog is available as usual <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/blob/heptapod-0.13.1/HEPTAPOD_CHANGELOG.md">with the sources</a></p>
<p>Heptapod 0.13.1 features a major refactoring of the way the main web
application is notified of Mercurial changes. Not only does this solve
a whole category of issues, but also it does prepare for the
future fully native Mercurial support (see the <a class="reference external" href="/pages/roadmap.html">roadmap page</a> for
more about this).</p>
<p>Heptapod 0.13.1 also sports an optional rewrite of the SSH support in
the Go programming language, which is the second technology preview
that was planned for the 0.13 series (see below how to activate
it). This solves the main blocker to base Heptapod on the currently
supported GitLab 12.10.</p>
<p>Heptapod 0.13.1 can be installed in Python 2 and Python 3 flavours as a
<a class="reference external" href="https://hub.docker.com/r/octobus/heptapod/tags?page=1&name=0.13.1">Docker image</a>
and
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/blob/heptapod-0.13.1/INSTALL_HEPTAPOD.md">from source</a>.</p>
<p>The public instances managed by <a class="reference external" href="https://octobus.net">Octobus</a> and <a class="reference external" href="https://clever-cloud.com">Clever Cloud</a>,
<a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a> and <a class="reference external" href="https://about.heptapod.host">heptapod.host</a> are already running Heptapod 0.13.1.</p>
<p>Please test with Python 3 and SSH support in Golang if you can,
and don't hesitate to give us feedback on our <a class="reference external" href="/pages/contact-us.html">communication channels</a>, it would be appreciated.</p>
<div class="section" id="ssh-support-how-to-activate-the-go-language-implementation">
<h2>SSH support: how to activate the Go language implementation</h2>
<p>First of all, thank you for wanting to give this technology preview a
try! This will help us test in advance what will become the standard
in future releases.</p>
<p>The case of source installations is treated in <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/blob/heptapod-0.13.1/INSTALL_HEPTAPOD.md#heptapod-shell-activating-the-golang-version-of-mercurial-ssh-support">the install instructions</a></p>
<p>Here is the configuration for Docker installations:</p>
<pre class="literal-block">
### Migration to Go feature flags
###! Docs: https://gitlab.com/gitlab-org/gitlab-shell#migration-to-go-feature-flags
gitlab_shell['migration'] = { enabled: true, features: ["hg"] }
</pre>
<p>You can put it in <tt class="docutils literal">/etc/gitlab/gitlab.rb</tt> and run
<tt class="docutils literal"><span class="pre">gitlab-ctl</span> reconfigure</tt>. No service restart is required.</p>
<p>Alternatively, you can put it in the the <tt class="docutils literal">GITLAB_OMNIBUS_CONFIG</tt> environment
variable for the whole container. In that case, restarting the
container will activate it.</p>
<p>This new optional feature being completely stateless, there is no
problem to switch it back off if needed.</p>
</div>
Heptapod 0.13.0 "dual python" released2020-05-29T00:00:00+02:002020-05-29T00:00:00+02:00Octobustag:heptapod.net,2020-05-29:/heptapod-0.13.0.html<p>We're glad to announce the release of Heptapod 0.13.0.</p>
<p>This version introduces support for wikis and is available in Python 2
and Python 3 variants, see the previous <a class="reference external" href="/py3-heptapod-0-13.html#py3-heptapod-0-13">article about Python 3</a>.</p>
<p>It also features major performance and scalability improvements for
Mercurial repository content over HTTP.</p>
<p>Heptapod 0 …</p><p>We're glad to announce the release of Heptapod 0.13.0.</p>
<p>This version introduces support for wikis and is available in Python 2
and Python 3 variants, see the previous <a class="reference external" href="/py3-heptapod-0-13.html#py3-heptapod-0-13">article about Python 3</a>.</p>
<p>It also features major performance and scalability improvements for
Mercurial repository content over HTTP.</p>
<p>Heptapod 0.13.0 can be installed in Python 2 and Python 3 flavours as a
<a class="reference external" href="https://hub.docker.com/r/octobus/heptapod/tags?page=1&name=0.13">Docker image</a>
and
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/blob/heptapod-0.13.0/INSTALL_HEPTAPOD.md">from source</a>.</p>
<p>The public instances managed by <a class="reference external" href="https://octobus.net">Octobus</a> and <a class="reference external" href="https://clever-cloud.com">Clever Cloud</a>,
<a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a> and <a class="reference external" href="https://about.heptapod.host">heptapod.host</a> are already running Heptapod 0.13.0.</p>
<p>Please test with Python 3 if you can, and don't hesitate to give us
feedback on our <a class="reference external" href="/pages/contact-us.html">communication channels</a>, we
love hearing from users.</p>
<div class="section" id="what-s-next">
<h2>What's next?</h2>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">we now have a <a class="reference external" href="/pages/roadmap.html">roadmap page</a>.</p>
</div>
<p>Under the hood, our Mercurial support was vastly refactored while
Heptapod 0.13 was under development, paving the way for the future Heptapod
0.14.</p>
<p>Heptapod 0.14 will be perhaps the most exciting and crucial of our
pre-1.0 versions. More information is available on the <a class="reference external" href="/pages/roadmap.html">roadmap page</a>.
Work on version 0.14 is starting now.</p>
<p>We don't see a compelling reason to plan for a 0.12.5 support version,
but don't hesitate to tell us if you really need one.</p>
</div>
Python 3 in Heptapod 0.132020-05-26T00:00:00+02:002020-05-26T00:00:00+02:00Octobustag:heptapod.net,2020-05-26:/py3-heptapod-0-13.html<p>A few days ago, Heptapod 0.13.0rc2 was released.</p>
<p>This is the first version with optional support for Python 3.</p>
<div class="figure">
<img alt="Detailed version information in Heptapod 0.13.0rc2 help page" class="screenshot" src="https://heptapod.net/images/heptapod-0.13.0rc2-versions.png" />
</div>
<p>In this post, we explain why it matters to test Heptapod with
Python 3 as soon as possible, and how to do so safely for your
Heptapod instance.</p>
<p>Running …</p><p>A few days ago, Heptapod 0.13.0rc2 was released.</p>
<p>This is the first version with optional support for Python 3.</p>
<div class="figure">
<img alt="Detailed version information in Heptapod 0.13.0rc2 help page" class="screenshot" src="https://heptapod.net/images/heptapod-0.13.0rc2-versions.png" />
</div>
<p>In this post, we explain why it matters to test Heptapod with
Python 3 as soon as possible, and how to do so safely for your
Heptapod instance.</p>
<p>Running with Python 3 should not change anything from users perspective,
but it's an important landmark for the sustainability of the Heptapod
project and it's been a fair amount of work.</p>
<p>Because we expect issues that could be related to the move to
Python 3 to be non obvious, we've decided to support both Python
versions for at least the whole Heptapod 0.13 development cycle, so
that any given instance can be switched back to Python 2 easily.</p>
<p>By running Heptapod with Python 3, you would help the Heptapod project
moving forward, while gaining better confidence that your use cases
will be well supported in the upcoming versions that may drop the
support for Python 2.</p>
<p>Of course Python 3 will be tested extensively on the instances managed
by Octobus and Clever Cloud.</p>
<div class="section" id="docker-running-with-python-3">
<h2>Docker: running with Python 3</h2>
<p>Starting with Heptapod 0.13.0rc2, we have two series of Docker images:</p>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">octobus/heptapod:0.13.0rc2-py2</span></tt></li>
<li><tt class="docutils literal"><span class="pre">octobus/heptapod:0.13.0rc2-py3</span></tt></li>
<li><tt class="docutils literal"><span class="pre">octobus/heptapod:latest-py2</span></tt></li>
<li><tt class="docutils literal"><span class="pre">octobus/heptapod:latest-py3</span></tt></li>
</ul>
<p>Running with Python 3 is as simple as using the <tt class="docutils literal">py3</tt> image.</p>
<p>There's no difference among these images except the Python version. If
you encounter trouble that could be related to Python 3, simply
restart with the <tt class="docutils literal">py2</tt> image and compare the outcome.</p>
<p>The default image (<tt class="docutils literal">octobus/heptapod:latest</tt> or
<tt class="docutils literal">octobus/heptapod:0.13.0rc2</tt>) still points to the <tt class="docutils literal">py2</tt> variant. If we get
satisfactory results, we may change that to the <tt class="docutils literal">py3</tt> variant for
Heptapod 0.13.1 or 0.13.2.</p>
<p>It's not clear at this time if Heptapod 0.14 can have Python 2
support. In any case Python 3 will be the default.</p>
</div>
<div class="section" id="source-installations-and-python-3">
<h2>Source installations and Python 3</h2>
<p>In a source installation, it's up to you to decide which Python
interpreter will have the Heptapod Python components (including
Mercurial), but we still advise to be ready to switch easily between
Python 2 and 3.</p>
<p>From 0.13.0rc2 onwards, the <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/blob/heptapod-0.13.0rc2/INSTALL_HEPTAPOD.md#be-ready-to-fallback-to-python-2">install instructions</a>
include a recommended deployment strategy meant precisely for easily
switching Python version, with almost no interruption of service.</p>
</div>
<div class="section" id="some-background">
<span id="background"></span><h2>Some background</h2>
<p>Mercurial is written primarily in the Python programming
language. Python 2 has reached its end of life this year. The new
version of the language, Python 3, has a vastly different and
incompatible way of handling strings and their encodings. This is
challenging for a version control system which, by definition, must be
able to handle content transparently, even if it doesn't have a
known and consistent encoding.
The change of type can cause mismatches in seldom used code paths in
libraries. This could for example be triggered by communicating with
external systems with unusual characteristics.</p>
<p>Python 3 support in Mercurial has been progressing gradually in recent
releases, and we believe 5.4 on Python 3 to be ready enough for
inclusion in Heptapod. Also, the last blocker on the road towards Python 3
has been removed with the <a class="reference external" href="https://groups.google.com/forum/#!topic/hg-git/f4cWCdgDEew">port of hg-git to Python 3</a>.</p>
</div>
Heptapod.host free beta extended2020-05-19T00:00:00+02:002020-05-19T00:00:00+02:00Octobustag:heptapod.net,2020-05-19:/free-beta-extended.html<p>Summary: The <a href="https://about.heptapod.host">Heptapod commercial service</a> will stay free of charge and in beta until the end of June.</p>
<p>In a <a href="/bb-new-deadline.html#bb-new-deadline">previous news item</a>,
we were commenting on the decision by Bitbucket to postpone the deadline before they
remove Mercurial repositories from their hosting by one month.</p>
<p>We were notably underlying …</p><p>Summary: The <a href="https://about.heptapod.host">Heptapod commercial service</a> will stay free of charge and in beta until the end of June.</p>
<p>In a <a href="/bb-new-deadline.html#bb-new-deadline">previous news item</a>,
we were commenting on the decision by Bitbucket to postpone the deadline before they
remove Mercurial repositories from their hosting by one month.</p>
<p>We were notably underlying at the time that it will give us more time to achieve the
major <a href="https://foss.heptapod.net/groups/heptapod/-/milestones/24">Heptapod 0.14</a> milestone, and put us well on the path to the eagerly expected
<a href="https://foss.heptapod.net/groups/heptapod/-/milestones/26">Heptapod 1.0</a>.</p>
<p>It made only sense to push the end date for our free beta period accordingly:</p>
<p><strong><a href="https://about.heptapod.host">heptapod.host</a> will be free of charge until June 30th.</strong></p>
<p>In other words, July 2020 will be the first month to be invoiced.</p>
<p>Enjoy!</p>Heptapod 0.13.0rc1 released: wikis and ground work2020-05-15T00:00:00+02:002020-05-15T00:00:00+02:00Octobustag:heptapod.net,2020-05-15:/heptapod-0.13.0rc1.html<p>We're glad to announce that the first release candidate for Heptapod
0.13 has just been released.</p>
<p>The main user visible feature that this new version brings is the
support for project wikis (see <a class="reference external" href="#wikis">details below</a>).</p>
<p>One of the main goals of the Heptapod 0.13 series is to provide …</p><p>We're glad to announce that the first release candidate for Heptapod
0.13 has just been released.</p>
<p>The main user visible feature that this new version brings is the
support for project wikis (see <a class="reference external" href="#wikis">details below</a>).</p>
<p>One of the main goals of the Heptapod 0.13 series is to provide a
firm basis to the major changes that will happen in the <a class="reference external" href="https://foss.heptapod.net/groups/heptapod/-/milestones/24">0.14
development cycle</a>.
This means that some core aspects are tighter with 0.13.0rc1 already
and it gives us the proper ground to fix some of the current issues.</p>
<p>Heptapod 0.13.0 will also sport two <a class="reference external" href="#tech-previews">technology previews</a> to help make the transition to 0.14 smoother.</p>
<p>So, <strong>please give 0.13.0rc1 a try, even if you don't care about wikis!</strong></p>
<p>The full changelog is available <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/blob/heptapod-0.13.0rc1/HEPTAPOD_CHANGELOG.md">alongside the sources</a>.</p>
<p>Heptapod 0.13.0rc1 is installable as a
<a class="reference external" href="https://hub.docker.com/r/octobus/heptapod">Docker image</a>
and
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/blob/heptapod-0.13.0rc1/INSTALL_HEPTAPOD.md">from source</a>
(don't miss the new Mercurial settings related to GitLab internal API).</p>
<p>Feel free to give us feedback on our
<a class="reference external" href="/pages/contact-us.html">communication channels</a>, we value all kinds
of contribution.</p>
<div class="section" id="wikis-1">
<span id="wikis"></span><h2>Wikis</h2>
<p>With 0.13.0rc1, GitLab wikis are expected to work in the Web UI and
are backed by Mercurial repositories.</p>
<p>The supported markups are the standard GitLab ones, Markdown, AsciiDoc
and RDoc together with limited added support for reStructuredText,
a common choice in Bitbucket repositories.</p>
<p>The Bitbucket importer does not yet import the wikis. The final
Heptapod 0.13.0 most probably will.</p>
<p>You can clone, pull and push to the wiki repository by adding <tt class="docutils literal">.wiki</tt> to
the URL. Some examples:</p>
<pre class="literal-block">
hg clone ssh://git@your.heptapod.example/group/proj.wiki
hg pull ssh://hg@foss.heptapod.net/group/proj.wiki
hg push https://your.heptapod.example/group/proj.wiki
</pre>
<p>The first of these URLS would be typical of a Docker installation (in
these, we inherit <tt class="docutils literal">git</tt> as the expected user from the parent GitLab image).</p>
</div>
<div class="section" id="technology-previews-in-heptapod-0-13">
<span id="tech-previews"></span><h2>Technology previews in Heptapod 0.13</h2>
<p>The Heptapod 0.13.x series will have two "technology
previews".</p>
<p>By testing them early, you would help us moving forward
towards Heptapod 1.0 while gaining better confidence that the upcoming
versions will work well on your projects.</p>
<p>These are not yet included in 0.13.0rc1, but we felt it
appropriate to give a glimpse of what will happen so that you can
prepare for them.</p>
<div class="section" id="python-3">
<span id="py3"></span><h3>Python 3</h3>
<p>To recall, Mercurial is written primarily in the Python programming
language. Python 2 has reached its end of life this year. The new
version of the language, Python 3, has a vastly different and
incompatible way of handling strings and their encodings. This is
challenging for a version control system which, by definition, must be
able to handle content transparently, even if it doesn't have a
known and consistent encoding.</p>
<p>Python 3 support in Mercurial has been progressing gradually in recent
releases, and we believe 5.4 on Python 3 to be ready enough for
inclusion in Heptapod. Also, the last blocker on the road towards Python 3
has been removed <a class="reference external" href="https://groups.google.com/forum/#!topic/hg-git/f4cWCdgDEew">earlier this week</a>.</p>
<p>This change warrants an extended testing period, and the means to
assess easily if a given problem is related to Python version. Here's
the plan:</p>
<ul class="simple">
<li>Heptapod 0.13.0 and subsequent 0.13.x versions should be able to run with
Python 2 or 3</li>
<li>Python 2 will stay the default at first, this may change after a few
intermediate releases.</li>
<li>on any Heptapod 0.13.x version, it will be possible to switch from
Python 2 to 3 and back without changing anything else: we will provide
Docker images for both and source installations would only need a
restart to switch Python versions.</li>
<li>Heptapod 0.14 should be for Python 3 only</li>
</ul>
</div>
<div class="section" id="gitlab-shell-1">
<span id="gitlab-shell"></span><h3>GitLab Shell</h3>
<p>GitLab Shell is the component responsible for interaction with SSH
clients. Originally written in Ruby, it has been undergoing a rewrite
in the Go language. This rewrite is fully ready yet still optional in GitLab
12.3, the base version for Heptapod 0.13. It becomes mandatory in
GitLab 12.4. That is why we make a stop at GitLab 12.3.</p>
<p>Our Heptapod Shell component is a modification of GitLab Shell that
adds SSH support for Mercurial, currently in Ruby only.</p>
<p>In the final Heptapod 0.13.0, we will provide an
optional rewrite of Heptapod Shell in the Go language.</p>
<p>This rewrite will become the standard in Heptapod 0.14, allowing us to
jump to the most recent GitLab 12 version possible (ideally 12.10 or 12.11).</p>
<p>It should be available for source installations, and possibly also
opted in through configuration in Docker setups.</p>
</div>
</div>
Bitbucket deadline postponed to July 1st2020-04-28T00:00:00+02:002020-04-28T00:00:00+02:00Georges Racinettag:heptapod.net,2020-04-28:/bb-new-deadline.html<p>Last week, Bitbucket updated their <a href="https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket">"sunsetting" announcement</a> with the new July 1st, 2020 deadline. Here we explore some implications of this piece of good news, for Heptapod and the Mercurial ecosystem.</p><p>Last week, Bitbucket updated their
<a href="https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket">"sunsetting" announcement</a>
with the new July 1st, 2020 deadline. Here we explore some implications
of this piece of good news, for Heptapod and the Mercurial ecosystem.</p>
<p>To quote the announcement: "Due to the impact of COVID-19, we are extending
the deprecation date by 30 days to give you more time to transition".</p>
<p>Many people have found the original 9 months to be short. It takes time to
explore alternatives, especially in a moving landscape: Since the original
Bitbucket announcement, some new
<a href="https://www.mercurial-scm.org/wiki/MercurialHosting">Mercurial hosting</a>
services have been launched, including of course
our own <a href="https://about.heptapod.host">heptapod.host</a>. These are getting stronger by the day.</p>
<p>We think this additional month could give Mercurial Bitbucket users
the opportunity to reevaluate their plans, especially for those that were
considering migration to another version control system: given the progress
made by Mercurial solutions, is it really worth the added disruption?</p>
<p>There are a lot of inactive repositories on Bitbucket. Many of them are at
risk to be lost forever. Fortunately, there is an ongoing
<a href="https://www.softwareheritage.org/2020/04/23/rescuing-250000-endangered-mercurial-repositories/">archival effort of public repositories</a> by <a href="https://www.softwareheritage.org/">Software Heritage</a>
in partnership with <a href="https://octobus.net">Octobus</a>, the creators of Heptapod. More on this and how
the Mercurial expertise of Octobus will be leveraged by Software Heritage can be
read <a href="https://octobus.net/blog/2020-04-23-heptapod-and-swh.html">here</a>.
One month more time
can only be good news for this rescue mission as well.</p>
<p>Let's turn ourselves to what Heptapod specifically has to offer right now
and where it should be by the end of June.</p>
<h2 id="current-state-of-heptapod-as-bitbucket-replacement">Current state of Heptapod as Bitbucket replacement</h2>
<p>As we've <a href="/heptapod-as-a-bitbucket-replacement.html#heptapod-as-a-bitbucket-replacement">already stated</a>, it was a primary concern at <a href="https://octobus.net">Octobus</a>
that someday Bitbucket could simply drop Mercurial support. Still, it
happened faster and more brutally than we feared.</p>
<p>That means we had to shift priorities. That let us to spend lots of time with
the rescue of Bitbucket repositories in mind:</p>
<ul>
<li>in autumn 2019, we fast tracked the development of the <a href="/pages/tuto-bb-import.html">Bitbucket import</a>
feature.</li>
<li>on December 10th, we <a href="/heptapod-as-a-bitbucket-replacement.html#heptapod-as-a-bitbucket-replacement">invited</a>
all generic projects related to <a href="https://mercurial-scm.org">Mercurial</a> to our own development instance</li>
<li>on January 27th, we <a href="/a-public-heptapod-for-free-and-open-source-software.html#a-public-heptapod-for-free-and-open-source-software">launched foss.heptapod.net</a>,
extending the former invitation to all Free and Open Source Software,
thanks to the partnership between <a href="https://octobus.net">Octobus</a> and <a href="https://clever-cloud.com">Clever Cloud</a>.</li>
<li>on April 6th, <a href="https://octobus.net">Octobus</a> and <a href="https://clever-cloud.com">Clever Cloud</a> started <a href="https://about.heptapod.host">heptapod.host</a>,
aiming to be the ultimate Bitbucket replacement. We formally
<a href="/heptapod-commercial-service-enters-free-public-beta.html#heptapod-commercial-service-enters-free-public-beta">announced</a> it as a free beta on April 20th.</li>
</ul>
<p>These are achievements we can be proud of, and they should already be enough
for many projects to migrate to Heptapod right now, be it on <a href="https://about.heptapod.host">heptapod.host</a>,
<a href="https://foss.heptapod.net">foss.heptapod.net</a> or a self-hosted instance. Let's see now what one more
month of development may bring us.</p>
<h2 id="heptapod-in-june-towards-version-10">Heptapod in June (towards version 1.0)</h2>
<p>We've always been very cautious about roadmaps, because we prefer to deliver
rather than to make promises. The Bitbucket situation alone only underlines
that all plans are liable to change due to external events.
That being said, Heptapod has made enough progress these past few months that
we can be more confident. Here are our current projections:</p>
<ul>
<li>Early May: <a href="https://foss.heptapod.net/groups/heptapod/-/milestones/21">Heptapod 0.13</a> will bring back the support for wikis, of course
with Bitbucket import. Development is well under way, things are looking good.</li>
<li>Early June: in <a href="https://foss.heptapod.net/groups/heptapod/-/milestones/24">Heptapod 0.14</a>, Mercurial repository web browsing starts
going native, as it's always been with a Mercurial client.
In the meanwhile, GitLab will reach version 13.0.0, and we'll try to land on
the closest 12.x as possible.</li>
</ul>
<p>In short, there was a risk that the previous Bitbucket deadline would
have found us still working on polishing Heptapod 0.14. Things will certainly
be much more comfortable this way.</p>
<p>What next in June, then? Heptapod 1.0, of course! We've always had two major
items to leave the realm of 0.x versions: catching up with upstream GitLab and
full native Mercurial support.</p>
<p>At this point, it is a mere possibility. Whether we reach 1.0 before Bibucket's
deadline or shortly after doesn't matter so much.
Heptapod 0.14 will be a strong version anyway, we don't need to rush.</p>Heptapod commercial service enters free public beta2020-04-20T00:00:00+02:002020-04-20T00:00:00+02:00Octobustag:heptapod.net,2020-04-20:/heptapod-commercial-service-enters-free-public-beta.html<p><a href="https://octobus.net">Octobus</a> and
<a href="https://clever-cloud.com">Clever Cloud</a>
launch <a href="https://about.heptapod.host">heptapod.host</a>, the commercial
Heptapod hosting solution. The service starts with a free public beta
phase until June 1st, 2020. The
<a href="https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket">demise of Bitbucket</a> is nearing and heptapod.host
is the ultimate Mercurial Bitbucket replacement.</p><p>We're proud to announce the launch of <a href="https://about.heptapod.host">heptapod.host</a>, a joint effort by
<a href="https://octobus.net">Octobus</a> and <a href="https://clever-cloud.com">Clever Cloud</a>. This is a general platform to host any Mercurial
project, private or not.</p>
<p>The service starts with a free public beta phase until June 1st, 2020. With the
<a href="https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket">demise of Bitbucket</a> nearing, heptapod.host
is the ultimate Mercurial Bitbucket replacement.</p>
<h2 id="how-to-use-the-service">How to use the service</h2>
<p>Once they have registered to the <a href="https://clever-cloud.com">Clever Cloud</a> platform and have created a
<a href="https://clever-cloud.com">Clever Cloud</a> organization, users may sign in to the
<a href="https://heptapod.host">Heptapod instance</a>.</p>
<p>Once signed in, users will find that their organizations have been mapped to
Heptapod groups in which they can create projects, or just import some from
Bitbucket (see below).</p>
<p>This is covered in more detail in the <a href="https://about.heptapod.host/register.html">registration tutorial</a>.</p>
<h2 id="pricing">Pricing</h2>
<p>Even though <a href="https://about.heptapod.host">heptapod.host</a> is in free beta until June 1st, 2020 a
<a href="https://about.heptapod.host/pricing.html">draft pricing policy</a> is already
available, together with concrete simulations.</p>
<p>This tentative pricing policy is based on the number of <em>active users</em> and
bandwith above a given threshold. It's there because we like to do things in
the open, and because we need to get your feedback. So, please come talk to
us about it.</p>
<h2 id="a-powerful-and-intuitive-bitbucket-import-capability">A powerful and intuitive Bitbucket import capability</h2>
<p>Importing from Bitbucket is a standard Heptapod feature. On <a href="https://about.heptapod.host">heptapod.host</a>,
it works exactly as explained in our <a href="/pages/tuto-bb-import.html">tutorial</a>.</p>
<p>It is in the inherent nature of distributed version control systems not to
suffer data loss upon disappearance of a central service, because
client repositories usually include the full history. Mercurial is of course
no exception to that.</p>
<p>But a modern collaborative plaftform for software development is about more
than source code repositories. What will happen with task management (issues),
and code review (pull requests)?</p>
<p>On top of the repository itself, Heptapod's import takes care of Bitbucket
<strong>issues and pull requests</strong>.
Not only do they become Heptapod (GitLab) issues
and merge requests, but they also <strong>keep their original numbering</strong>.</p>
<p>This latter feature will help keeping the disruption low for lots of project:
it is indeed common that commit messages reference issues or pull requests
by number, be it in an explicit form (<code>#123</code>) or as a link
(<code>https://bitbucket.org/my/repo/issues/123</code>). How many of us developers have
been frustrated, trying to understand a change done a while ago
because such references have become useless in the meanwhile? How many emails
or spreadsheets turned into useless noise because of that?
After an import to Heptapod, these references will still be understandable.</p>
<h2 id="the-companies-setting-up-this-service">The companies setting up this service</h2>
<h3 id="octobus-development">Octobus: development</h3>
<p><a href="https://octobus.net">Octobus</a> is a company focussing on commercial support for the Mercurial
source control system.
Besides providing most of the work force in Heptapod development, their work
ranges from workflow consulting to ad-hoc development for companies needing
performance boosts or custom features.</p>
<p>Most of Octobus development happens upstream, so that
Octobus provides a significant part of current Mercurial core
development. In particular, in the last couple of years,
Octobus has been driving the ongoing effort to use the Rust programming
language in Mercurial, improving both the performance and the robustness
of the codebase.</p>
<h3 id="clever-cloud-hosting">Clever Cloud: hosting</h3>
<p><a href="https://clever-cloud.com">Clever Cloud</a> is a Europe-based PaaS company. They help developers deploy and
run their apps with bulletproof infrastructure, automatic scaling, fair pricing
and other cool features. They aim to make an easy-to-use service,
without any vendor lock-in and able to grow with customer needs.</p>
<p>On top of their strong admin and ops expertise, they are actually are
a developer first company and a software vendor themselves. As such
they know and understand the value of end to end delivery and the importance
of the right Software Factory.</p>Scheduled downtime of foss.heptapod.net for upgrade2020-04-18T00:00:00+02:002020-04-18T00:00:00+02:00Octobustag:heptapod.net,2020-04-18:/scheduled-downtime-of-fossheptapodnet-for-upgrade.html<p>Exceptionally, <a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a> will be offline next
Monday, April 20th 2020 from 10:00 UTC+2, only to be back in the
evening. Read this to know why and why it won't happen again.</p>
<p><a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a> is the Heptapod service hosting
Free and Open Source Software offered free …</p><p>Exceptionally, <a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a> will be offline next
Monday, April 20th 2020 from 10:00 UTC+2, only to be back in the
evening. Read this to know why and why it won't happen again.</p>
<p><a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a> is the Heptapod service hosting
Free and Open Source Software offered free of charge by <a class="reference external" href="https://octobus.net">Octobus</a> and <a class="reference external" href="https://clever-cloud.com">Clever Cloud</a>.</p>
<div class="section" id="catching-up-on-two-major-gitlab-versions">
<h2>Catching up on two major GitLab versions</h2>
<p>So, next Monday, we're going to upgrade <a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a> to
<a class="reference external" href="https://heptapod.net/heptapod-0120-released-featuring-gitlab-12.html#heptapod-0120-released-featuring-gitlab-12">Heptapod 0.12.0</a>.</p>
<p>That means jumping from GitLab 10.5 to 12.2, crossing twice the new
major version line. Here lies the issue.</p>
<div class="section" id="gitlab-s-standard-upgrade-process">
<span id="upstream"></span><h3>GitLab's standard upgrade process</h3>
<p>Reference: <a class="reference external" href="https://docs.gitlab.com/ce/policy/maintenance.html#upgrade-recommendations">GitLab upgrade recommandations</a></p>
<p>GitLab has a lot of data migrations to perform on
upgrades, some of which are deferred to actually run in the background
<em>after</em> the upgrade.
Forward porting these migrations can't be done forever, and at some
point, the current software must be able to assume that the data
structure is recent enough. So they have to draw a line: the policy
states that to cross a major version, one must be sure that
the previous background migrations have been fully completed.</p>
<p>Here's an example of what it should have looked like for an
installation going from GitLab 11.10 to 12.0:</p>
<ol class="arabic simple">
<li>Upgrade to GitLab 11.11</li>
<li><em>Keep running</em> at least until the background migrations are
done. On the largest installations, that can amount to almost a
week, but it doesn't matter: users can work normally in the
meantime.</li>
<li>Upgrade to GitLab 12.0</li>
</ol>
<p>For an installation that is always upgraded shortly after the GitLab
release, the waiting part happens naturally: there's a whole
month between 11.11 and 12.0 anyway.</p>
</div>
<div class="section" id="heptapod-0-12-0-migration">
<h3>Heptapod 0.12.0 migration</h3>
<p>Reference: <a class="reference external" href="/heptapod-0120-rc-featuring-gitlab-12.html#migrate-0-12">how to migrate to 0.12.0</a></p>
<p>In the case of Heptapod, we don't have fully functional versions
based on GitLab 10.8, 11.0 and 11.11, as it would have been a
disproportionate effort to do so, and that would have impaired our ability
to really catch up. Instead, we have intermediate versions that can't
be used for anything but performing the data migrations.</p>
<p>So that means we can't have the users enjoying the service while it's
silently finishing to upgrade in the background: we have to wait for
it to finish.</p>
</div>
<div class="section" id="the-case-of-foss-heptapod-net">
<h3>The case of foss.heptapod.net</h3>
<p>GitLab background migrations are geared towards limiting load and
concurrency on the largest instances. This is achieved by cutting some
tasks in chunks and waiting a lot between tasks.</p>
<p>While not at the same scale as <a class="reference external" href="https://gitlab.com/explore">gitlab.com</a>,
our <a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a> is large enough that the cutting and waiting
happens, with disproportionately long delays.</p>
<p>As a consequence, our test run for the upgrade of <a class="reference external" href="https://foss.heptapod.net">foss.heptapod.net</a>
took about 7 hours.
We've lowered some of the delays since then, but there's so much we
can do without taking excessive risks.</p>
<p>We know that long downtimes are bad, and we aren't pleased with that
situation. But we found it better for everyone if our users can enjoy
this major improvement in a few days and if we can focus on improving
Heptapod rather than delay the upgrade and spend time watching test
runs for an operation that will happen just once.</p>
</div>
</div>
<div class="section" id="why-it-won-t-happen-next-time">
<h2>Why it won't happen next time</h2>
<p>GitLab 13.0 is
<a class="reference external" href="https://about.gitlab.com/upcoming-releases">due on 2020-05-22</a></p>
<p>Fortunately, we're now much closer to current GitLab versions:
instead of being more that two major versions behind, we're now less that
one. That's the whole point of Heptapod 0.12.0.</p>
<p>In a nutshell, the transition of Heptapod to GitLab 13 will happen exactly
as <a class="reference external" href="#upstream">explained above</a> for upstream GitLab: we'll make a
fully functional version of Heptapod based on GitLab 12.10. The next
one, based on 13.0 will be several weeks later.</p>
</div>
Heptapod 0.12.0 released, featuring GitLab 122020-04-07T00:00:00+02:002020-04-07T00:00:00+02:00Octobustag:heptapod.net,2020-04-07:/heptapod-0120-released-featuring-gitlab-12.html<p>We're very pleased to announce that Heptapod 0.12.0 has been released.
<strong>DO NOT MIGRATE DIRECTLY</strong> from previous versions. Please read
<a class="reference external" href="/heptapod-0120-rc-featuring-gitlab-12.html#migrate-0-12">how to migrate</a>
from our previous announcement.</p>
<p>This version will be the basis for the <a class="reference external" href="https://clever-cloud.com/en/heptapod">commercial
service</a> by Octobus and Clever
Cloud, entering public beta in a short …</p><p>We're very pleased to announce that Heptapod 0.12.0 has been released.
<strong>DO NOT MIGRATE DIRECTLY</strong> from previous versions. Please read
<a class="reference external" href="/heptapod-0120-rc-featuring-gitlab-12.html#migrate-0-12">how to migrate</a>
from our previous announcement.</p>
<p>This version will be the basis for the <a class="reference external" href="https://clever-cloud.com/en/heptapod">commercial
service</a> by Octobus and Clever
Cloud, entering public beta in a short while.</p>
<p>The main goal of this development cycle was to catch up to GitLab as
much as possible in one jump, and that's what we did, going from GitLab 10.5.8
to 12.2.12, who's been released less than 4 months ago.</p>
<p>Heptapod 0.12.0 is installable as a
<a class="reference external" href="https://hub.docker.com/r/octobus/heptapod">Docker image</a>.
and
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/blob/heptapod-0.12.0-1/INSTALL_HEPTAPOD.md">from source</a></p>
<p>Don't hesitate to give us feedback on our
<a class="reference external" href="/pages/contact-us.html">communication channels</a>, we're eager to hear it.</p>
<div class="section" id="what-else-is-new-in-0-12-0">
<h2>What else is new in 0.12.0?</h2>
<p>Jumping from GitLab CE 10.5.8 to 12.2.12 carries itself an impressive
list of features, but that's not the only achievement we've had
in Heptapod 0.12.0.</p>
<p>For instance, a rewrite of our internals has led to major
push performance improvements, especially for larger repositories.</p>
<p>The maturation phase for this release has been longer than with the previous
ones. For this reason, the <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/blob/heptapod-0.12.0-1/HEPTAPOD_CHANGELOG.md">full changelog</a>,
has a separate section to highlight the changes from 0.8.4 directly.</p>
<p>Note also that the changelog is now located with the main sources
instead of with the Docker image definition.</p>
</div>
<div class="section" id="continuous-integration">
<h2>Continuous integration</h2>
<p>The previously available versions of Heptapod Runner,
our dedicated fork of GitLab Runner, is expected not to work with
Heptapod 0.12.0. The main reason for that is that its base GitLab
Runner version is not compatible with GitLab 12.2.</p>
<p>Therefore, Heptapod Runner has seen a major revamp, too, with <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod-runner/tags/heptapod-0.2.0rc2">version
0.2.0rc2</a>
being the required minimum to work with Heptapod 0.12.0.</p>
<p>We took the opportunity to make it work for regular GitLab
installations as well, meaning that users happening to maintain
a GitLab instance alongside their Heptapod shouldn't have to manage
two separate swarms of runners, provided that all versions are compatible.
This is quite fresh and we'd be
happy to have more user feedback about such mixed use cases,
so don't hesitate to tell us if that works for you and how we could
improve it.</p>
<p>Heptapod Runner is versioned and released separately from other
components. We expect the final 0.2.0 to be released next week.</p>
</div>
Heptapod 0.12.0 RC, featuring GitLab 122020-03-18T00:00:00+01:002020-03-18T00:00:00+01:00Octobustag:heptapod.net,2020-03-18:/heptapod-0120-rc-featuring-gitlab-12.html<p>We're very excited to announce that Heptapod reached the 0.12.0rc3
version today.
<strong>DO NOT MIGRATE DIRECTLY</strong> from previous versions.</p>
<p>If you've been following our announcements, you must wonder what happened
with Heptapod 0.9, that would be the logical version number after
0.8.3. That part should …</p><p>We're very excited to announce that Heptapod reached the 0.12.0rc3
version today.
<strong>DO NOT MIGRATE DIRECTLY</strong> from previous versions.</p>
<p>If you've been following our announcements, you must wonder what happened
with Heptapod 0.9, that would be the logical version number after
0.8.3. That part should be clear once you've read <a class="reference external" href="#migrate-0-12">how to migrate</a> below.</p>
<p>This new version is very special, in that it sports a giant leap from
GitLab 10.5 to GitLab CE 12.2, catching up on most our lag behind
upstream GitLab, down from 666 days for Heptapod 0.8.3 to merely 96
for 0.12.0rc3.</p>
<p>But that's not the only novelty, we're also expecting
very significant performance gains on larger repositories.
In any case, see the <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/blob/branch/heptapod-0-12/INSTALL_HEPTAPOD.md">full
changelog</a>
in its new source location.</p>
<p>Our public instance for FOSS projects, <a class="reference external" href="https://foss.heptapod.net">https://foss.heptapod.net</a>,
should be migrated as soon as we are satisfied with the tests we are
going to perform now in staging. We will cut the final
0.12.0 once we are satisfied with how it behaves in production.</p>
<p>This new version should also be the basis for the <a class="reference external" href="https://clever-cloud.com/en/heptapod">joint commercial
service</a> by Octobus and Clever
Cloud, that should enter its alpha stage as soon as possible, now.</p>
<p>Really, Heptapod 0.12 should be nicknamed "under the sign of twelve"
or something alike:
it is based on GitLab 12.2.12 and moreover, our tracking issue for
that move is #212. We swear, that didn't happen on purpose.</p>
<p>Don't hesitate to give us your feedback, we're eager to hear it.</p>
<div class="section" id="how-to-migrate-from-prior-heptapod-versions">
<span id="migrate-0-12"></span><h2>How to migrate from prior Heptapod versions</h2>
<p>Needless to say, the general rule to keep a data backup is as relevant
as ever.</p>
<div class="section" id="a-series-of-intermediate-migration-versions">
<h3>A series of intermediate migration versions</h3>
<p>GitLab's migration system doesn't support crossing several major
versions at once: doing so would be incompatible with its background
migrations. This is explained in <a class="reference external" href="https://docs.gitlab.com/ce/policy/maintenance.html#upgrade-recommendations">GitLab upgrade recommandations</a>.</p>
<p>Therefore, migrating from Heptapod 0.8 to Heptapod 0.12 is no
exception: it requires to stop at appropriate intermediate GitLab versions.</p>
<p>It would have been pointless and a huge waste of time to make a whole
functional Heptapod for all of these, so we made intermediate versions
that can do only a single thing well: migrate your data. These are
labelled Heptapod 0.9, 0.10, and 0.11.</p>
<p>At the time of this writing, these intermediate versions all are
release candidates as well, and will maintain that status until the
final Heptapod 0.12.0 is released.</p>
</div>
<div class="section" id="performing-the-migrations">
<h3>Performing the migrations</h3>
<p>You should make sure to grab the latest available of each of the
intermediate versions, especially if you're trying with release candidates.</p>
<p>Docker users will find images for the intermediate versions under the
familiar names: <tt class="docutils literal">octobus/heptapod:0.9.0rc1</tt> etc. Please check for the
latest releases on <a class="reference external" href="https://hub.docker.com/r/octobus/heptapod/tags">Docker Hub</a>.</p>
<p>For source installations, the tags also follow the usual namings:
<tt class="docutils literal"><span class="pre">heptapod-0.9.0rc1</span></tt> and so forth.</p>
<p>For each of these intermediate version you'll have to:</p>
<ol class="arabic">
<li><p class="first">install and start it.</p>
</li>
<li><p class="first">wait for the background migrations <a class="reference external" href="https://docs.gitlab.com/ce/update/#checking-for-background-migrations-before-upgrading">to be complete</a></p>
<p>Here is how to access the Rails console:</p>
<ul class="simple">
<li>for Docker installations:
<tt class="docutils literal">docker exec <span class="pre">-it</span> CONTAINER_ID <span class="pre">gitlab-rails</span> console</tt></li>
<li><dl class="first docutils">
<dt>for source installations: from the Rails directory, run</dt>
<dd><tt class="docutils literal">bundle exec rails console environment=PRODUCTION</tt></dd>
</dl>
</li>
</ul>
</li>
</ol>
<p>Once the background migrations for Heptapod 0.11 are done, you can finally
upgrade normally to 0.12.</p>
<p>A few more details about migrations are provided in the
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod/blob/branch/heptapod-0-12/INSTALL_HEPTAPOD.md">installation instructions</a></p>
<p>If you have any problem, don't hesitate to reach out to us on our
Mattermost or file an issue directly.</p>
</div>
</div>
Heptapod News, mid February2020-02-10T00:00:00+01:002020-02-10T00:00:00+01:00Georges Racinettag:heptapod.net,2020-02-10:/heptapod-news-mid-february.html<p>Following the launch of our public instance for FOSS projects, we've
presented it at FOSDEM, started to onboard projects, released version
0.8.2 and been provided CI resources by the OSU OSL.</p>
<div class="section" id="heptapod-at-fosdem">
<h2>Heptapod at FOSDEM</h2>
<p>The whole Octobus development team was at
<a class="reference external" href="https://fosdem.org/2020/">FOSDEM 2020</a> where we
made also junction …</p></div><p>Following the launch of our public instance for FOSS projects, we've
presented it at FOSDEM, started to onboard projects, released version
0.8.2 and been provided CI resources by the OSU OSL.</p>
<div class="section" id="heptapod-at-fosdem">
<h2>Heptapod at FOSDEM</h2>
<p>The whole Octobus development team was at
<a class="reference external" href="https://fosdem.org/2020/">FOSDEM 2020</a> where we
made also junction with Laurent and Quentin from Clever Cloud.</p>
<p>I gave a lightning talk on the second day about the whole Heptapod
project and in particular the launch of the <a class="reference external" href="foss.heptapod.net">public FOSS instance</a>.</p>
<p>As usual with the excellent organization at FOSDEM,
the slides and the video are available on the <a class="reference external" href="https://fosdem.org/2020/schedule/event/heptapod_mercurial/">talk page</a>.</p>
<video preload="none" controls="" width="100%" height="auto">
<source
src="https://video.fosdem.org/2020/H.2215/heptapod_mercurial.webm"
type="video/webm">
<source
src="https://video.fosdem.org/2020/H.2215/heptapod_mercurial.mp4"
type="video/mp4">
Your browser does not support the video tag.
</video></div>
<div class="section" id="new-administrators-and-projects-on-the-public-foss-instance">
<h2>New administrators and projects on the public FOSS instance</h2>
<p>Since the original <a class="reference external" href="https://heptapod.net/a-public-heptapod-for-free-and-open-source-software.html#a-public-heptapod-for-free-and-open-source-software">announcement</a>,
we've welcomed three volunteer administrators on foss.heptapod.net,
who are not affiliated with Octobus nor Clever Cloud. This
is in line with our wish to make this public service community managed.</p>
<p>We've drafted a process to treat <a class="reference external" href="https://foss.heptapod.net/heptapod/foss.heptapod.net/issues?label_name%5B%5D=Hosting+Request">Hosting Requests</a>,
and started to onboard projects:</p>
<ul class="simple">
<li>the Mercurial group will soon welcome some more extensions and
TortoiseHg, the well-known graphical user interface</li>
<li>we have some <a class="reference external" href="https://foss.heptapod.net/bsdutils">BSD utilities</a>
under way.</li>
<li>The import of <a class="reference external" href="https://www.pypy.org">PyPy</a> is scheduled to happen on
February 12th. This will be the biggest and most complex import from
Bitbucket that we've performed – one that has actually been our
major test bed for the importer.
At almost 100 000 changesets, it will come a close second to
<a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod">Heptapod itself</a> in
terms of repository size.</li>
</ul>
</div>
<div class="section" id="osu-osl-backing-up-foss-public-instance-ci">
<h2>OSU OSL backing up FOSS public instance CI</h2>
<p>Continuous Integration (CI) is naturally a major aspect of public
service hosting for free and open source software. With more projects
to join us, we expect the required computing resources to be
substantial. So we've started to look for partnerships in that area.</p>
<p>If you are involved in an organization that would be willing to grant
us some processing power in the benefit of free and open source
software, don't hesitate to <a class="reference external" href="/pages/contact-us.html#contact-us">contact us</a>!</p>
<p>Last week, we've been granted servers by the <a class="reference external" href="https://osuosl.org">OSU Open Source Lab</a> and we set them up as shared runners for the
continuous integration on the FOSS public instance. One can see them
running pipeline jobs right now.</p>
<p>This is a great development, many thanks to the OSU OSL for this!</p>
<p>Quoting from the OSU OSL web site:</p>
<blockquote>
<p>The Open Source Lab is a nonprofit organization working for the
advancement of open source technologies.</p>
<p>The lab, in partnership with the School of Electrical Engineering
and Computer Science at Oregon State University, provides hosting
for more than 160 projects, including those of worldwide leaders
like the Apache Software Foundation, the Linux Foundation and
Drupal. Together, the OSL’s hosted sites deliver nearly 430
terabytes of information to people around the world every month. The
most active organization of its kind, the OSL offers world-class
hosting services, professional software development and
on-the-ground training for promising students interested in open
source management and programming.</p>
</blockquote>
</div>
<div class="section" id="heptapod-0-8-2-released">
<h2>Heptapod 0.8.2 released</h2>
<p>Since <a class="reference external" href="heptapod-080-released.html#heptapod-080-released">version 0.8.0</a>, we've had two
bugfix releases.</p>
<p>The first, 0.8.1 was mostly about tidying things up for the launch of
foss.heptapod.net, while 0.8.2 fixes some problems found after
everything has been reimported into the new install at Clever Cloud.</p>
<p>For a precise list, see the regular <a class="reference external" href="https://foss.heptapod.net/heptapod/heptapod-docker/blob/branch/heptapod-0-8/heptapod/CHANGES.md">changelog</a>.</p>
</div>
<div class="section" id="what-else">
<h2>What else ?</h2>
<p>I've got a working experimental version of Heptapod running on top of
GitLab 11.2 and it looks like 12.2 is just around the corner.</p>
</div>
A public Heptapod for Free and Open Source Software2020-01-28T00:00:00+01:002020-01-28T00:00:00+01:00Octobustag:heptapod.net,2020-01-28:/a-public-heptapod-for-free-and-open-source-software.html<p>On January 27th, 2020, Octobus and Clever Cloud have launched a free
service for Free and Open Source Software (FOSS). Maintainers of
FOSS projects using Mercurial and looking for a new home
are invited to apply to use the service</p><p>We have exciting news to share with the Mercurial community today.</p>
<p>Thanks to the
partnership between <a href="https://octobus.net">Octobus</a> and
<a href="https://clever-cloud.com">Clever Cloud</a>, we are bringing up a public Heptapod
service for Free and Open Source Software (FOSS).</p>
<p>This new service is available from January 27th, 2020, and will be
ready to gradually onbard FOSS projects soon after.</p>
<p>This is just a first step, we are also
<a href="https://www.clever-cloud.com/en/heptapod">working on a commercial service</a> that we
hope to launch in February.</p>
<h2 id="eligibility-for-hosting-on-fossheptapodnet">Eligibility for hosting on foss.heptapod.net</h2>
<p>This free service is set up and sponsored by Clever Cloud and Octobus.
Since neither of these two companies has
a business model based on mining user data nor the prospect of being
bought of by a big multinational, we can't commit to give away unlimited
resources. We'd be lying anyway if we did.</p>
<p>Therefore we require that projects to be hosted</p>
<ul>
<li>are really Free and Open Source (OSI approved license), not just public.</li>
<li>acknowledge the help on their official web page by inserting links and logos
to Clever Cloud and Octobus at the appropriate place, e.g, on the page that
provides the development instructions.</li>
<li>put only really relevant repositories on foss.heptapod.net, the reason being that we
can't afford to host thousands of repositories whose usefulness would be
doubtful.</li>
</ul>
<p>These rules are subject to interpretation and will be enforced by human beings
(see next section).</p>
<p>In the context of Bitbucket dropping support for Mercurial, we'll also give
priority to projects that are currently hosted at Bitbucket – they need a new
home as soon as possible.</p>
<p>Generally speaking, to maximize the positive impact of this public service,
we'll give priority to mature projects with a significant user base, producing
releases on official channels.</p>
<p>Finally, we encourage project maintainers to reach out to us if they feel
the rules are not applicable in their case, but that their project should
morally be on foss.heptapod.net. Perhaps we can come up with solutions, but
remember: Heptapod is itself FOSS, anybody can install it already. The upcoming
commercial service may well turn out to be the most efficient solution in some cases.</p>
<h2 id="how-to-apply">How to apply</h2>
<ul>
<li>open an <a href="https://foss.heptapod.net/heptapod/foss.heptapod.net/issues/new">issue on the tracking project for the FOSS instance</a>.</li>
<li>please use the predefined <code>Hosting Request</code> template and label.</li>
</ul>
<h2 id="a-community-managed-service">A community managed service</h2>
<p>Our intent is to provide a service for the community, managed
by the community.</p>
<p>We are currently setting up a team for administration of foss.heptapod.net,
that will include from the onset people that are neither Octobus nor
Clever Cloud employees.</p>
<p>This team will in particular be in charge of accepting new projects and
facilitate their on-boarding.</p>
<p>The full policy isn't written yet, but we plan to have a path for gradual
cooptation of new administrators and evolution of the policy. All of this
should happen as much as possible in the open, perhaps just by discussion
of Merge Requests.</p>
<h2 id="what-has-happened-with-devheptapodnet">What has happened with dev.heptapod.net?</h2>
<p>Short answer: it has <em>become</em> foss.heptapod.net.</p>
<p>Heptapod was hosting itself and some Mercurial related projects
at <a href="https://dev.heptapod.net">dev.heptapod.net</a>, a server entirely managed
by Octobus.</p>
<p>We found it quite logical, and simpler for everybody involved to simply
reinstall it at <a href="https://foss.heptapod.net">foss.heptapod.net</a> and declare it
to be the public Heptapod instance for FOSS projects.</p>
<h3 id="noticeable-differences">Noticeable differences</h3>
<ul>
<li>SSH URLs for Mercurial operation have changed from
<code>ssh://git@dev.heptapod.net</code> to <code>ssh://hg@foss.heptapod.net</code> (notice the
user part)</li>
</ul>
<h2 id="what-version-of-heptapod-does-fossheptapodnet-run">What version of Heptapod does foss.heptapod.net run?</h2>
<p>The latest released one, starting with version 0.8.1, released on 2020-01-23.</p>Heptapod 0.8.0 released2020-01-17T00:00:00+01:002020-01-17T00:00:00+01:00Octobustag:heptapod.net,2020-01-17:/heptapod-080-released.html<p>We're glad to announce the release of Heptapod 0.8.0.</p>
<p>An image is available on <a class="reference external" href="https://hub.docker.com/r/octobus/heptapod">Docker Hub</a>, and this version is
also the first one to be installable <a class="reference external" href="https://dev.heptapod.net/heptapod/heptapod/blob/branch/heptapod-0-8/INSTALL_HEPTAPOD.md">from source</a></p>
<p>Deploying this version performs several significative data migrations. Care must
be applied to backup all data before upgrading.</p>
<p>It's …</p><p>We're glad to announce the release of Heptapod 0.8.0.</p>
<p>An image is available on <a class="reference external" href="https://hub.docker.com/r/octobus/heptapod">Docker Hub</a>, and this version is
also the first one to be installable <a class="reference external" href="https://dev.heptapod.net/heptapod/heptapod/blob/branch/heptapod-0-8/INSTALL_HEPTAPOD.md">from source</a></p>
<p>Deploying this version performs several significative data migrations. Care must
be applied to backup all data before upgrading.</p>
<p>It's been a crowded development cycle, as we are readying ourselves
for public hosting at
<a class="reference external" href="https://www.clever-cloud.com/en/heptapod">Clever Cloud</a>, thanks to
a partnership with <a class="reference external" href="https://octobus.net">Octobus</a>.</p>
<p>Building on the groundwork layed down in Heptapod 0.7.0, several major
targets have been attained in this new version:</p>
<ul class="simple">
<li>SSH support</li>
<li>Install from source</li>
<li>Full import of Bitbucket Pull Requests</li>
</ul>
<p>Further important foundational work has been done: we're hoping to offer
contributors a much better experience in the near future (see below),
and finally, work on the HGitaly project has started for good.</p>
<p>A proper release for Heptapod Runner is likely to follow in the next
few days. We hope to be able to have it release itself, that would be
satisfying.</p>
<p>As usual, the full changelog for Heptapod 0.8.0 can be read online
<a class="reference external" href="https://dev.heptapod.net/heptapod/heptapod-docker/blob/branch/heptapod-0-8/heptapod/CHANGES.md">alongside the Dockerfile</a>
and in the full description of the images in Docker Hub.</p>
<p>Heptapod is Free and Open Source software. If you want it to shine,
the best is to contribute or to hire someone to do so. We've had a
<a class="reference external" href="https://dev.heptapod.net/groups/heptapod/-/issues?label_name%5B%5D=Easier">category of issues</a>
lately that don't require much knowledge. Many of these are
about improving the user experience, so don't hesitate!</p>
<div class="section" id="towards-a-better-contributing-experience">
<span id="hdk"></span><h2>Towards a better contributing experience</h2>
<p>In the course of the preparation for installation from source, we've been
working with a modified version of the <a class="reference external" href="https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/README.md">GitLab Development Kit (GDK)</a></p>
<p>It's obviously a far superior way of working, especially for anything
related to the Rails application.</p>
<p>For now it's merely a collection of local hacks and it's not very
stable. Of course, we're planning to make an official version. Maybe
that'd be a HDK, but the exact form it's going to take has not been decided yet.</p>
</div>
Heptapod gains SSH support in version 0.8.0rc12019-12-25T00:00:00+01:002019-12-25T00:00:00+01:00Octobustag:heptapod.net,2019-12-25:/heptapod-gains-ssh-support-in-version-080rc1.html<p>Those of you that have been following the issues and merge requests on
dev.heptapod.net won't be surprised that the winter solstice release
of Heptapod finally gets the very much awaited feature of SSH pushes
and pulls.</p>
<p>This is now on <a class="reference external" href="https://hub.docker.com/r/octobus/heptapod">Docker Hub</a> as usual, as the
0.8 …</p><p>Those of you that have been following the issues and merge requests on
dev.heptapod.net won't be surprised that the winter solstice release
of Heptapod finally gets the very much awaited feature of SSH pushes
and pulls.</p>
<p>This is now on <a class="reference external" href="https://hub.docker.com/r/octobus/heptapod">Docker Hub</a> as usual, as the
0.8.0rc1 version.</p>
<p>Please give it serious testing in controlled conditions: opening new
authentication methods always comes at a risk, even if that relies
mostly on already proven infrastructure as this is the case here.</p>
<div class="section" id="maturation-of-the-0-8-0-version">
<h2>Maturation of the 0.8.0 version</h2>
<p><a class="reference external" href="faster-upgrades-on-our-heptapod-instances.html#faster-upgrades-on-our-heptapod-instances">In a normal week</a>, we'd have already
installed it on the instances that
Octobus directly manages and would been gathering early feedback from
our direct users.</p>
<p>However, with the year's end coming close, the activity is a bit too
sparse for this to be really relevant. We'll be dogfooding this
version as soon as it is reasonable – that should be just a few days
worth of delay.</p>
<p>In the meanwhile, we'll write more tests,
tighten some screws and bolts, so that we can release if possible a
robust 0.8.0 during the first week of 2020.</p>
<p>If you want to help making that release, install 0.8.0rc1 on a testing
server and throw all you can at it to breach it! We'd be more than
happy to correct problems early.</p>
</div>
<div class="section" id="what-else">
<h2>What else?</h2>
<p>Heptapod 0.8.0rc1 also bumps the GitLab base version from 10.3.9 to
10.5.8. This time we put our development <a class="reference external" href="https://dev.heptapod.net/heptapod/heptapod/issues/127">branches closer to those of
upstream GitLab</a>. It's been a
bit hairy, but it will make next upgrades much easier.</p>
<p>The Bitbucket import of <a class="reference external" href="https://dev.heptapod.net/heptapod/heptapod/issues/106">Pull Requests from forks</a> is mostly ready
– it just has not been merged yet and requires more testing.
It will be part of a forthcoming Heptapod 0.7.1, whose improvements
will also be merged in Heptapod 0.8.0.</p>
</div>
Heptapod as a BitBucket replacement2019-12-10T00:00:00+01:002019-12-10T00:00:00+01:00Octobustag:heptapod.net,2019-12-10:/heptapod-as-a-bitbucket-replacement.html<p>Many times over the past few months, we've been asked if Heptapod was to be
the perfect haven for teams in search of a new DVCS home after they must flee
from Bitbucket?</p>
<p>We're hereby <strong>inviting all generic projects related
to Mercurial on <a href="https://dev.heptapod.net">our main Heptapod instance</a></strong>.
Read below for …</p><p>Many times over the past few months, we've been asked if Heptapod was to be
the perfect haven for teams in search of a new DVCS home after they must flee
from Bitbucket?</p>
<p>We're hereby <strong>inviting all generic projects related
to Mercurial on <a href="https://dev.heptapod.net">our main Heptapod instance</a></strong>.
Read below for more
details about that, the current state of our Bitbucket import feature, and
future hosting plans.</p>
<h2 id="its-always-been-part-of-the-plan">It's always been part of the plan</h2>
<p>To recall, on August, 20th of this year, BitBucket <a href="https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket">announced</a> that they
will be dropping support for Mercurial in the first semester of 2020,
culminating by the removal of all Mercurial repositories on June 1st, 2020.</p>
<p>When Octobus launched the Heptapod project, we had two
goals. The first was to showcase a clear and focused way to use modern
features of Mercurial, and especially its history rewriting capabilities.
Some of that is detailed in our <a href="https://octobus.net/blog/2019-09-04-heptapod-workflow.html">workflow blog post</a>.</p>
<p>The other goal was precisely to provide an alternative people could
turn themselves to, should Bitbucket drop Mercurial support.
While we had reasons to fear that this could happen, we didn't expect it
to happen so fast. What we didn't foresee either was the rise of
<a href="https://hg.sr.ht/">sourcehut</a>, which looks indeed like the perfect solution
for email based workflows.</p>
<p>Since Bitbucket's announcement, we've been working hard to bring Heptapod up
to speed to serve as a possible replacement, putting a stronger focus on import
features.</p>
<h2 id="importing-projects-from-bitbucket-into-heptapod">Importing projects from Bitbucket into Heptapod</h2>
<p>Importing from Bitbucket is a standard GitLab feature, of course restricted to
Git repositories in upstream GitLab. Although we had to deactivate it in the
early Heptapod prototype, it's been rather straightforward to bring it back.</p>
<p>The Bitbucket import works in Heptapod as in upstream GitLab, except of course
that it's currently for Mercurial repositories only. If you want to use it
on your own instance, just follow the <a href="https://docs.gitlab.com/ce/user/project/import/bitbucket.html">standard instructions</a>.</p>
<p>During the Heptapod 0.6 timeframe, we did many experiments involving the
Bitbucket import. Notably, we made several test runs for the PyPy project,
an interesting case with its 95000 changesets, lots of issues and a worklow
with named branches based on the issue number. Of course, that import takes
quite some time, but it works.</p>
<p>There is a <a href="https://dev.heptapod.net/heptapod/heptapod/issues?label_name%5B%5D=Bitbucket">specific category of Heptapod issues</a>
about the Bitbucket import. We currently lack an important one (Pull Requests
from forks), but we are confident it'll be available in a couple of weeks.</p>
<h2 id="inviting-mercurial-projects-on-devheptapodnet">Inviting Mercurial projects on dev.heptapod.net</h2>
<p>We decided long ago that the main instance for development of Heptapod itself
could also host projects directly related to Mercurial. It started because we
thought some pieces needed for Heptapod would be more generic anyway, but it
quicly outgrown that.</p>
<p>So, dev.heptapod.net has long had a <a href="https://dev.heptapod.net/mercurial">group of Mercurial generic
projects</a>. We've imported some extensions
that we care about ourselves since then, such as <code>config-express</code>,
<code>format-source</code> and most recently, <code>hg-git</code>. These benefit right now from our
powerful Continuous Integration (CI).</p>
<p>As a service and contribution to the Mercurial community, we're
<strong>now inviting all open-source projects related to
Mercurial that are hosted on Bitbucket to come over to dev.heptapod.net</strong>.</p>
<p>For that to happen, you'll have to <a href="https://dev.heptapod.net/heptapod/dev.heptapod.net/issues">file an issue in the tracker for
dev.heptapod.net</a>,
with the <code>Hosting Request</code> label. All discussions about it shall be public.</p>
<p>Here are the requirements the repository to import has to fulfill:</p>
<ul>
<li>related to Mercurial: that includes extensions of course, but also external
tooling, such as graphical interfaces, server utilities.</li>
<li>currently hosted on Bitbucket: we want to focus on projects that are in
need of new home soon.</li>
<li>fully Free/Libre Open Source projects only. By the way, everything on
dev.heptapod.net is public.</li>
<li>be the main development repository, the reason being that we don't want to
host hundreds of secondary clones there, whose relevance wouldn't be clear.</li>
<li>have official releases. More generally, we'll give priority to mature
projects with a significant user base, or that we are using ourselves.</li>
</ul>
<p>This list is by no means complete. Some of these requirements might be
tightened up or loosened in the future. Basically, we'll see how it goes and
adjust accordingly.</p>
<p>If in doubt, just file an issue anyway. Be assured that we'll be gentle if we
have to tell you that your project does not belong there.</p>
<h2 id="plans-for-general-hosting">Plans for general hosting</h2>
<p>Public hosting is a resource-intensive endeavor that requires lots
of work force or process automation, especially with the delicate subject
of moderation.</p>
<p>Heptapod is still currently developped and hosted primarily by Octobus. Being
a small consulting company, Octobus doesn't have extensive hosting capabilities
by itself, hence can't do this <em>alone</em>.</p>
<p>What Octobus <em>can do</em> however is to explore partnership opportunities with
existing hosting companies in order to build a commercial offer and explore
possibilities for shared public hosting.</p>
<p>This is what we are doing now. It's too early to be really specific. Just stay
tuned.</p>Heptapod 0.7.0 released2019-12-05T00:00:00+01:002019-12-05T00:00:00+01:00Octobustag:heptapod.net,2019-12-05:/heptapod-070-released.html<p>We're glad to announce the release of Heptapod 0.7.0, on <a class="reference external" href="https://hub.docker.com/r/octobus/heptapod">Docker Hub</a>.</p>
<p>Deploying this version performs several significative data migrations. Care must
be applied to backup all data before upgrading.</p>
<p>It's been an exciting development cycle, laying the ground for the
major advances of the next one. We …</p><p>We're glad to announce the release of Heptapod 0.7.0, on <a class="reference external" href="https://hub.docker.com/r/octobus/heptapod">Docker Hub</a>.</p>
<p>Deploying this version performs several significative data migrations. Care must
be applied to backup all data before upgrading.</p>
<p>It's been an exciting development cycle, laying the ground for the
major advances of the next one. We had notably:</p>
<ul class="simple">
<li>base software version updates for the first time (GitLab 10.3.9,
Mercurial 5.2 / Evolve 9.2.1), and a systematic strategy to upgrade
GitLab in the future</li>
<li>more direct serving of Mercurial repositories</li>
<li>better consistency in the exposition of Mercurial to the GitLab
application layer (essential for CI)</li>
</ul>
<p>and last but not least, we got the <strong>Continuous Integration</strong>
officially supported, thanks to the launch of the Heptapod Runner project,
derived from early experiments by the fine people at Logilab.</p>
<p>As usual, the full changelog can be read online <a class="reference external" href="https://dev.heptapod.net/heptapod/heptapod-docker/blob/branch/heptapod-0-7/heptapod/CHANGES.md">alongside the
Dockerfile</a>
and in the full description of the images in Docker Hub.</p>
<div class="section" id="heptapod-and-bitbucket">
<h2>Heptapod and Bitbucket</h2>
<p>Heptapod has a Bitbucket import feature that is nearing completion,
and is already sufficient in many cases.</p>
<p>We've switched a few projects from Bitbucket to our Heptapod instances,
and performed interesting experiences in the timeframe of our 0.6.x
series. This will be the subject of a later post.</p>
<p>Interested people can watch
our <a class="reference external" href="https://dev.heptapod.net/heptapod/heptapod/issues?label_name%5B%5D=Bitbucket">Bitbucket issues list</a>.</p>
<p>To summarize, there are only two missing features to declare our
Bitbucket import to be complete:</p>
<ul class="simple">
<li>Pull Requests from forks</li>
<li>Issue attachments</li>
</ul>
<p>We plan to develop them in the 0.7.x series.</p>
<p>There's little doubt we'll be
in a very good position to provide a seamless Bitbucket replacement by
their first deadline of Feb 1st.</p>
</div>
<div class="section" id="a-stable-branch-for-heptapod-0-7">
<h2>A stable branch for Heptapod 0.7</h2>
<p>We're adopting a workflow in which a new series, such as 0.7.x, 0.8.x
is preceded by a release branch, morphing naturally into a stable
branch, from which the subsequent point releases will be made.</p>
<p>The goal is to make our upgrades of the base GitLab version easier to
perform and more robust.</p>
<p>This is explained in detail in
<a class="reference external" href="https://dev.heptapod.net/heptapod/heptapod/issues/127">https://dev.heptapod.net/heptapod/heptapod/issues/127</a>.</p>
</div>
<div class="section" id="ongoing-development-of-heptapod-0-8">
<h2>Ongoing development of Heptapod 0.8</h2>
<p>The goals for the new development cycle are:</p>
<ul class="simple">
<li>to develop SSH support. Some of the underlying infrastructure has
been set in place in 0.7.0.</li>
<li>to start the <tt class="docutils literal">hgitaly</tt> project, our implementation of the Gitaly
protocol for Mercurial. Everything appears to be set in place for
that, although it won't probably enter service before a couple of cycles.</li>
<li>to bump the GitLab base version to 10.4 or 10.5. Which one depends
actually on the time other developments will take.</li>
</ul>
</div>
Faster upgrades on our Heptapod instances2019-11-06T00:00:00+01:002019-11-06T00:00:00+01:00Octobustag:heptapod.net,2019-11-06:/faster-upgrades-on-our-heptapod-instances.html<p>In short, <a class="reference external" href="https://dev.heptapod.net">https://dev.heptapod.net</a> and other instances managed by Octobus will
get GitLab base version upgrades up to once a week in the foreseeable future.</p>
<div class="section" id="the-goal-catching-up-on-gitlab-base-versions">
<h2>The goal: catching up on GitLab base versions</h2>
<p>Since the inception of Heptapod, first as a prototype, the version of
GitLab upon which …</p></div><p>In short, <a class="reference external" href="https://dev.heptapod.net">https://dev.heptapod.net</a> and other instances managed by Octobus will
get GitLab base version upgrades up to once a week in the foreseeable future.</p>
<div class="section" id="the-goal-catching-up-on-gitlab-base-versions">
<h2>The goal: catching up on GitLab base versions</h2>
<p>Since the inception of Heptapod, first as a prototype, the version of
GitLab upon which it is based has not been significantly updated,
still being at 10.1. Now that Heptapod is gaining more traction, it's
really time to do something about that.</p>
<p>In parallel with the Heptapod 0.6 series, some preparation work has
been done to help us rebase Heptapod easily onto more recent GitLab
versions, and we made successful experiments to jump to 10.2, then
10.3.</p>
<p>Side note: it's really satisfying that fat merge commits can not only be
done in topics, but also that rebasing them works like a
charm. There's something to be said for developers tackling the
general cases by default.</p>
<p>GitLab 10.2 has already been merged in the main Heptapod branch. We'd
like to push it further to 10.3 for Heptapod 0.7.</p>
</div>
<div class="section" id="testing-strategy">
<h2>Testing strategy</h2>
<p>While that doesn't sound too ambitious, one has to take into account
that GitLab releases a minor version, such as 10.2.0, 10.3.0 every
month. To state the obvious, we have to go significantly faster than that to
catch up.</p>
<p>There is no way
the Heptapod developers can test all the changes in a typical GitLab
minor version. For example, the changelog of 10.3.0 mentions has 127 entries.
Instead, we'll have to rely on:</p>
<ul class="simple">
<li>targetting the latest stable version of each series. This is what
we've already done, with GitLab 10.2.8 and 10.3.9.</li>
<li>GitLab's own QA. For changes that have nothing with
repositories themselves, this should be enough.</li>
<li>our <a class="reference external" href="https://dev.heptapod.net/heptapod/heptapod-tests">functional test suite</a>,
that guarantees that Mercurial centric features do work.</li>
<li>dog fooding and community testing. This is how we'll catch issues
in the interaction with Mercurial and GitLab that aren't covered yet
by the various automatic testing systems.</li>
</ul>
</div>
<div class="section" id="upgrade-policy">
<h2>Upgrade policy</h2>
<p>Starting with intermediate versions before Heptapod 0.7,</p>
<ul class="simple">
<li>the <tt class="docutils literal">latest</tt> Docker image will be updated regularly with a new
minor GitLab version.</li>
<li>all instances managed by Octobus will be upgraded in the following few
days</li>
<li>only minimal manual testing will happen before the instance upgrades.</li>
<li>the instance upgrade rate can be as high as weekly.</li>
<li>upgrades of internal Octobus instances will happen on Mondays.</li>
<li>upgrades of <a class="reference external" href="https://dev.heptapod.net">https://dev.heptapod.net</a> will happen on Tuesdays.</li>
<li>all instance upgrades will be announced at least 4 hours in advance.</li>
</ul>
<p>To all these instance users: please report issues on
<a class="reference external" href="https://dev.heptapod.net">https://dev.heptapod.net</a>, including the exact Heptapod revison, as can
be read on the help page. Here's <a class="reference external" href="https://dev.heptapod.net/help">an example</a></p>
<p>We still have a long way to go, and we're just ramping up, but the
more we'll move forward, the easier it will get, because Heptapod
will benefit from its own improvements.</p>
</div>
Heptapod 0.6.2 released2019-10-31T00:00:00+01:002019-10-31T00:00:00+01:00Octobustag:heptapod.net,2019-10-31:/heptapod-062-released.html<p>We're glad to announce the release of Heptapod 0.6.2, on <a class="reference external" href="https://hub.docker.com/r/octobus/heptapod">Docker Hub</a>.</p>
<p>This version is mostly about improving the imports, notably from
Bitbucket. The full changelog can be read online <a class="reference external" href="https://dev.heptapod.net/heptapod/heptapod-docker/blob/branch/heptapod-0-6-stable/heptapod/CHANGES.md">alongside the
Dockerfile</a>
and in the full description of the images in Docker Hub.</p>
<div class="section" id="a-stable-branch-for-heptapod-0-6">
<h2>A stable branch for …</h2></div><p>We're glad to announce the release of Heptapod 0.6.2, on <a class="reference external" href="https://hub.docker.com/r/octobus/heptapod">Docker Hub</a>.</p>
<p>This version is mostly about improving the imports, notably from
Bitbucket. The full changelog can be read online <a class="reference external" href="https://dev.heptapod.net/heptapod/heptapod-docker/blob/branch/heptapod-0-6-stable/heptapod/CHANGES.md">alongside the
Dockerfile</a>
and in the full description of the images in Docker Hub.</p>
<div class="section" id="a-stable-branch-for-heptapod-0-6">
<h2>A stable branch for Heptapod 0.6</h2>
<p>With this version, for the first time, we've decided to fork our
development process into two branches, with branches named along the
lines of <tt class="docutils literal"><span class="pre">heptapod-0-6-stable</span></tt> for the 0.6 series and
<tt class="docutils literal">heptapod</tt> or <tt class="docutils literal">default</tt> for the upcoming Heptapod 0.7.</p>
<p>Indeed, with Heptapod 0.6, we reached a point where the overall
behaviour of Mercurial in the GitLab context is satisfying enough that we can
be comfortable just improving on it or fixing bugs without taking
risks for our users.</p>
<p>It's already almost sure that there will be a 0.6.3, with at least more
improvements of the Bitbucket import.</p>
</div>
<div class="section" id="ongoing-development-of-heptapod-0-7">
<h2>Ongoing development of Heptapod 0.7</h2>
<p>Thanks to the existence of the 0.6 stable branch, we'll be free to
engage in a more aggressive approach for the ongoing 0.7 development,
that happens in parallel:</p>
<ul class="simple">
<li>Bumps of the base upstream GitLab versions. These will lead us to a
bolder update policy on instances managed by Octobus, notably
dev.heptapod.net.</li>
<li>Reorganisation of Mercurial configuration files (HGRCs), bringing us
group-level HGRCs, and leading the way to development of dedicated
management interfaces in the farther future.</li>
<li>More inner technical refactoring, making the interplay between
GitLab and Mercurial more direct and robust.</li>
</ul>
</div>
BitBucket and GitHub login and registration on dev.heptapod.net2019-10-11T00:00:00+02:002019-10-11T00:00:00+02:00Octobustag:heptapod.net,2019-10-11:/bitbucket-and-github-login-and-registration-on-devheptapodnet.html<p>Today, we've configured dev.heptapod.net, the self-hosted development
instance of Heptapod, for login and registration with BitBucket and
GitHub accounts.</p>
<p>This makes it a breeze to register a new account and start filing
issues, commenting on Merge Requests, etc.</p>
<p>Existing users have to activate the feature explicitely (see below …</p><p>Today, we've configured dev.heptapod.net, the self-hosted development
instance of Heptapod, for login and registration with BitBucket and
GitHub accounts.</p>
<p>This makes it a breeze to register a new account and start filing
issues, commenting on Merge Requests, etc.</p>
<p>Existing users have to activate the feature explicitely (see below).</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">one still needs to ask us for explicit permission grant in
order to push topics and create Merge Requests.</p>
</div>
<div class="section" id="a-bit-of-background">
<h2>A bit of background</h2>
<p>It should not come as a surprise: GitLab has powerful single-sign-on (SSO)
capabilities. It is able to perform as an <a class="reference external" href="https://en.wikipedia.org/wiki/OAuth">OAuth 2.0</a> and <a class="reference external" href="https://en.wikipedia.org/wiki/OpenID_Connect">OpenID Connect (OIDC)</a> Provider as well as a Consumer.</p>
<p>OpenId Connect (OIDC) provides the ability to use a third party for
authentication, and that's what we did today, with BitBucket and
GitHub OIDC Providers.</p>
<p>All of this ships with GitLab Community Edition and is of course
readily available within Heptapod, with no specific development on our
side, because it's orthogonal to repository matters.</p>
<p>This is a good example of the benefits we were hoping to reap with our
strategy to extend a fully integrated forge: repository support is
actually but a tiny fraction of the GitLab code base. Furthermore, the
<a class="reference external" href="https://docs.gitlab.com/ce/integration/omniauth.html">official documentation</a> is applicable
to Heptapod.</p>
<p>The BitBucket importer also relies on OAuth 2.0, with a broader set of
permissions to be able to fetch the repository content. We've been
able to make it work with just <a class="reference external" href="https://dev.heptapod.net/heptapod/heptapod/merge_requests/30">minimal adjustments</a>.</p>
</div>
<div class="section" id="for-new-users">
<span id="sso-sign-up"></span><h2>For new users</h2>
<p>On the Sign in page, don't fill any form field, just click on the
BitBucket or GitHub logo.</p>
<div class="figure">
<img alt="Sign in page for dev.heptapod.net" src="https://heptapod.net/images/dev_heptapod_net_sign_in.png" />
</div>
<p>You will be redirected if needed to the chosen provider for
authentication and to grant explicit permission to read your necessary
account information. Once you've done it, that's it, you're
registered and signed in.</p>
<p>Next time, you won't need to grant permission. You'll just have to authenticate
with the SSO provider if needed.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">you'll have to set a password if later on you want to push
Mercurial changesets.</p>
</div>
</div>
<div class="section" id="for-existing-users">
<span id="sso-sign-in"></span><h2>For existing users</h2>
<p>As a mandatory step, you need to connect you Heptapod account to the
wished external Provider account.</p>
<div class="admonition warning">
<p class="first admonition-title">Warning</p>
<p class="last">all SSO sign-in attempts from a Provider that has not been
connected will result in a 422 error page.</p>
</div>
<p>In your personal Settings area, select the "Account" tool, scroll
down go to "Social sign-in":</p>
<div class="figure">
<img alt="Account settings, Social sign-in section" src="https://heptapod.net/images/gitlab_account_sso_activation.png" />
</div>
<p>After clicking on the relevant "Connect" button, you'll be redirected
to the chosen Provider for authentication if needed, and asked to
grant explicit permission to access the necessary account
information.</p>
<p>Once that has been done, you will be able to log in directly from the Heptapod
sign-in page: don't fill any form field, just click on the appropriate
Provider logo.</p>
<div class="figure">
<img alt="Sign in page for dev.heptapod.net" src="https://heptapod.net/images/dev_heptapod_net_sign_in.png" />
</div>
<p>From now on, you won't need to grant the permission again. You'll just
have to authenticate with the SSO provider if needed.</p>
</div>
Heptapod 0.6.1 released2019-10-01T00:00:00+02:002019-10-01T00:00:00+02:00Octobustag:heptapod.net,2019-10-01:/heptapod-061-released.html<p>We're glad to announce the release of Heptapod 0.6.1, on <a class="reference external" href="https://hub.docker.com/r/octobus/heptapod">Docker Hub</a>.</p>
<p>This version contains several fixes that improve the
reliability of imports for mature projects and handles the closing of
named branches properly. It also re-enables the
<strong>import from Bibutcket</strong> as a beta feature.</p>
<p>The full changelog …</p><p>We're glad to announce the release of Heptapod 0.6.1, on <a class="reference external" href="https://hub.docker.com/r/octobus/heptapod">Docker Hub</a>.</p>
<p>This version contains several fixes that improve the
reliability of imports for mature projects and handles the closing of
named branches properly. It also re-enables the
<strong>import from Bibutcket</strong> as a beta feature.</p>
<p>The full changelog can be read online <a class="reference external" href="https://dev.heptapod.net/heptapod/heptapod-docker/blob/branch/default/heptapod/CHANGES.md">alongside the
Dockerfile</a>
and in the full description of the images in Docker Hub.</p>
<p>Also, in the same timeframe, our <a class="reference external" href="https://dev.heptapod.net">public development instance</a> is now <strong>open to registration</strong>.</p>
<div class="section" id="beta-import-from-bitbucket">
<h2>Beta: import from Bitbucket</h2>
<p>GitLab CE sports a feature to import projects from Bitbucket, that we
had to disable early in the Heptapod project, because it could not
work at the time for Mercurial repositories.</p>
<p>Besides the repository itself, the GitLab Bitbucket import takes care
of issues and Merge Requests. We didn't test the latter yet.</p>
<p>With the "import from URL" ready in Heptapod
0.6.0, we expected the full Bitbucket import to be around the
corner. And indeed, it was.</p>
<p>The work we did for Heptapod 0.6.1 about the Bitbucket import does not go
far beyond making the option visible again, and declaring that
Mercurial repositories are indeed importable.</p>
<p>Since it worked so easily, we found it appropriate to make it
available to our users right away. We don't expect it to work
for all projects, but it's a start, and if it works for you, then you're
all set.</p>
<p>If you come across problems, we'll be glad to hear about them
in our <a class="reference external" href="https://dev.heptapod.net/heptapod/heptapod/issues">issue tracker</a>,
especially if your case is easy to reproduce (small public project).</p>
<p>Of course we'll upstream any relevant fix to GitLab.</p>
</div>
<div class="section" id="closing-heads">
<h2>Closing heads</h2>
<p>The primary goal of closing a branch is to stop seeing it by
default. One can hence consider that it was a bug of Heptapod 0.6.0
not to remove the branch from the GitLab interface.</p>
<p>Also <tt class="docutils literal">commit <span class="pre">--closes-branch</span></tt> has been used a lot in the past to clean up
multiple heads conditions, and because of that, not discarding
closing changesets from the GitLab side was an impediment for the good
operation of Heptapod. Indeed, counting the closed heads as multiple
heads prevented new updates of the branch on the GitLab side or even
its creation in imports.</p>
<p>In particular, the results we got while testing
the import of the <a class="reference external" href="https://bitbucket.org/pypy/pypy">PyPy project</a>,
with its 16 closed heads on the <tt class="docutils literal">default</tt> branch alone did not leave any
room for doubt.</p>
<p>All of this is controlled by two new HGRC flags, whose names speak for
themselves.</p>
<div class="section" id="backwards-compatibility">
<h3>Backwards compatibility</h3>
<p>With 0.6.1, by default, pushing the closing of a
branch will have it removed from the GitLab interface, but nothing
happens to closed branches or heads that have already made their way
to GitLab.</p>
<p>Nevertheless, if you'd like to keep the previous behaviour, you can
<a class="reference external" href="/pages/faq.html#hgrc">use the following HGRC snippet</a>:</p>
<pre class="literal-block">
[experimental]
hg-git.prune-previously-closed-branches = no
hg-git.prune-newly-closed-branches = no
</pre>
</div>
<div class="section" id="breaking-change-scheduled-for-0-7-0">
<h3>Breaking change scheduled for 0.7.0</h3>
<p>We plan for 0.7.0 to remove all closed heads or branches from
GitLab. This will be done by changing the default value of the
relevant HGRC flag.</p>
<p>If you want to stick with the 0.6.1 behaviour, just <a class="reference external" href="/pages/faq.html#hgrc">use the following
HGRC snippet</a>:</p>
<pre class="literal-block">
[experimental]
hg-git.prune-previously-closed-branches = no
</pre>
</div>
</div>
Heptapod 0.6.0 released2019-09-17T00:00:00+02:002019-09-17T00:00:00+02:00Octobustag:heptapod.net,2019-09-17:/heptapod-060-released.html<p>We're glad to announce the release of Heptapod 0.6.0, on <a class="reference external" href="https://hub.docker.com/r/octobus/heptapod">Docker Hub</a>.
This version adds workflow and import features, and makes contributing
easier.</p>
<p>While the 0.5 series was mostly about fixing the automatic detection
of merges done by pushing public changesets directly from the command
line, this …</p><p>We're glad to announce the release of Heptapod 0.6.0, on <a class="reference external" href="https://hub.docker.com/r/octobus/heptapod">Docker Hub</a>.
This version adds workflow and import features, and makes contributing
easier.</p>
<p>While the 0.5 series was mostly about fixing the automatic detection
of merges done by pushing public changesets directly from the command
line, this new version should allow Heptapod user base to grow beyond its
current core of early adopters, thanks to two important user features:</p>
<ol class="arabic simple">
<li>The intended <a class="reference external" href="https://octobus.net/blog/2019-09-04-heptapod-workflow.html">default simple and elegant workflow</a> is provided
out of the box.</li>
<li>The standard GitLab "import from URL" feature has been finally
ported to Mercurial.</li>
</ol>
<p>On top of that, we made some preparations to make it easier to
contribute to Heptapod (lots of low hanging fruits in the UI!),
had a minor base GitLab version bump for the
first time, and of course fixed a handful of bugs.</p>
<p>A traditional changelog is provided in the full description of the
Docker image, with emphasis on backwards compatibility. In the
remainings of this post, we'd like to focus on the possibilities that
this new version opens.</p>
<div class="section" id="workflow-1">
<span id="workflow"></span><h2>Workflow</h2>
<p>The creators of Heptapod had this vision from the
beginning of the project: not only to provide the Merge Request
centric workflow that is currently the paradigm of open development
but also to have it integrated by default with the
non-destructive history rewriting capabilities of current Mercurial
with changeset evolution and topics:
safe and easy squashes, splits, rebases, you name it. No need to be a
DVCS expert, no need to jeopardize a whole project by force pushing on
a regular basis.</p>
<p>This is done by a series of server side decisions. All of these are
explained and motivated in the <a class="reference external" href="https://octobus.net/blog/2019-09-04-heptapod-workflow.html">Heptapod workflow blogpost</a>.
The end result is that</p>
<ul class="simple">
<li>topics are for short-lived feature branches, they are fully
rewritable (<tt class="docutils literal">draft</tt> phase).</li>
<li>non-topic changesets are completely immutable, as in
traditional Mercurial, and writable to the project Master role only.</li>
</ul>
<p>For projects that can't or won't work in this way, be it for deep
reasons or transitional in nature, the server-side settings that enforce this
can be changed, see the <cite>FAQ workflow section </pages/faq.html#workflow</cite>.</p>
</div>
<div class="section" id="import-from-url">
<span id="url-import"></span><h2>Import from URL</h2>
<p>Because of various timeouts that can't be reasonably set to very long
values, creating a new Project by a direct push is not realistic for
large projects. Fortunately, GitLab comes with the machinery to import
from various Git sources, and in particular from BitBucket.</p>
<p>In this version, we started with the most generic import: creating a
Project by the HTTP URL of a remote repository.</p>
<div class="figure">
<img alt="Import project tab, after selection of "Hg repo by URL"" src="https://heptapod.net/images/import-project.png" />
<p class="caption">The "import project" tab of the Project creation page, after
selection of "Hg repo by URL"</p>
</div>
<p>People interested into migrating from Bitbucket and needing to carry
issues, merge requests etc. over can already use it for an early test,
knowing that the full Bitbucket import is probably just around the corner.</p>
<div class="section" id="limitations">
<span id="import-limitations"></span><h3>Limitations</h3>
<p>This Mercurial import is rather young and we know
there's a good variety of pathological cases around, so we don't
expect it to work in all situations.</p>
<ul class="simple">
<li>the import feature has its own timeout, set by default to 800 seconds,
that can be modified by the instance's systems adminstrator.</li>
<li>the import can fail on <strong>repositories with instability</strong>
orphan changesets, divergent ones. Try and have the most of
instability resolved before importing.</li>
</ul>
<p>We'll fix problematic cases in the forthcoming releases, but for that,
we need them to be reported on <a class="reference external" href="https://dev.heptapod.net">https://dev.heptapod.net</a>, and if it's
about publically available repositories, you won't even need to send
us the logs, the URL will be enough.</p>
</div>
</div>
<div class="section" id="development-process">
<h2>Development process</h2>
<p>Various actions were taken to make it easier to integrate external
contributors and to streamline our development.</p>
<div class="section" id="project-management">
<h3>Project management</h3>
<p>In this cycle we also started to</p>
<ul class="simple">
<li>rework <a class="reference external" href="https://dev.heptapod.net/groups/heptapod/milestones">our milestones</a>. These will
serve as a roadmap for the time being, but we won't hesitate to
postpone issues.</li>
<li>put <a class="reference external" href="https://dev.heptapod.net/groups/heptapod/labels">labels</a> on
our issues</li>
</ul>
</div>
<div class="section" id="developer-tools">
<h3>Developer tools</h3>
<ul class="simple">
<li>the full description of the <a class="reference external" href="https://hub.docker.com/r/octobus/heptapod-dev">heptapod-dev</a>
Docker image will serve as a contributor's guide</li>
<li>the <a class="reference external" href="https://dev.heptapod.net/heptapod/omnibus">build-launch</a> script
makes it easier to get working on a local Docker container.</li>
</ul>
</div>
</div>
Heptapod 0.4.0 released2019-07-17T00:00:00+02:002019-07-17T00:00:00+02:00Octobustag:heptapod.net,2019-07-17:/heptapod-040-released.html<p>We're glad to announce that version 0.4.0 of Heptapod has been
released on 2019-07-09.</p>
<p>This version contains an overhaul of Mercurial logs, with Sentry
integration.</p>
<p>We also took this opportunity to give the Docker image its long due <tt class="docutils literal">README</tt>.</p>
<p>This new logging system leverages the
brand new <a class="reference external" href="https://dev.heptapod.net/heptapod/hgext-loggingmod">loggingmod …</a></p><p>We're glad to announce that version 0.4.0 of Heptapod has been
released on 2019-07-09.</p>
<p>This version contains an overhaul of Mercurial logs, with Sentry
integration.</p>
<p>We also took this opportunity to give the Docker image its long due <tt class="docutils literal">README</tt>.</p>
<p>This new logging system leverages the
brand new <a class="reference external" href="https://dev.heptapod.net/heptapod/hgext-loggingmod">loggingmod</a>
Mercurial extension, which provides the Sentry integration out of the box.</p>
<p>Enjoy!</p>