Heptapod Development Kit available
Contributing to Heptapod has just become much easier, thanks to the introduction of the Heptapod Development Kit (HDK).
Since the beginning of this year, we've been using a custom modified version of the GitLab Development Kit (GDK) for most Heptapod development. However, it didn't go much beyond replacing git by hg 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.
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!
We encourage all interested persons to reach out to us on our communication channel. We're eagerly awaiting your feedback!
How to get started?
Come talk to us on our communication channel and follow the instructions in the README.
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.
Is the HDK mandatory to contribute to Heptapod?
No, it's not.
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.
Let's not forget that not all contributions are code: all that one needs to improve the builtin documentation, for example, is a clone of the sources. If one wants to see it rendered within the application, then it's possible to apply the changes directly in the Docker image.
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.
Finally some components are self-contained and self-tested enough to be developed independently. For instance, py-heptapod and HGitaly have comprehensive test suites that allow to reproduce and fix bugs, or implement features if enough specifications are available.
What does the Heptapod Development Kit do?
The HDK has the same set of responsibilities than the GDK:
- clone all the source repositories, with consistent revisions
- retrieve all the needed dependencies: hundreds of Ruby gems, Golang libraries, Node.js packages and Python distributions
- build everything
- prepare development and testing databases
- provide service management (gdk start etc.)
Here are the differences with the GDK:
- 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, default, stable…).
- Additional Python components, including the target Mercurial version are installed. This is done in the venv3 and venv2 virtualenvs, with a venv symlink allowing to switch from Python 3 to Python 2 and back easily.
- There's a specific hg-http service, currently running Gunicorn, as in the source installation instructions. Soon, we'll have a hgitaly service as well.
At this point, the forked components still bear their original GitLab name, e.g. gitlab/ (Rails application), gitlab-workhorse/ etc. This might change in the future.