- Jul 30, 2020
-
-
Georges Racinet authored
-
- Jul 29, 2020
-
-
Georges Racinet authored
We bump the base upstream image and use a direct revision of heptapod-rails, in which v13.1.5 has been merged.
-
- Jul 28, 2020
-
-
Georges Racinet authored
For RCs, HEPTAPOD_VERSION and the tag aren't identical, the first has a dot (this matches what is done in GitLab's VERSION)
-
- Jul 24, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
Because Python3 is now the default, this will save us a few minutes before the testing image gets available, which is being nice to release managers, especially under stress.
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jul 16, 2020
-
-
Georges Racinet authored
For this we're using intermediate revisions from the current main branches, for a first round of tests before 0.15.0rc1
-
- Jul 22, 2020
-
-
Georges Racinet authored
-
- Jul 17, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
This script hasn't been used for a release from a stable branch since its inception.
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jul 16, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
This way the second build will reuse the Go binaries we just built and chances to get a critical security bugfix in between builds are very slim
-
- Jul 07, 2020
-
-
Georges Racinet authored
We need both the new versions of Heptapod components and to use an updated base image.
-
- Jun 30, 2020
-
-
Georges Racinet authored
-
- Jun 29, 2020
-
-
Georges Racinet authored
-
- Jun 26, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jun 24, 2020
-
-
Georges Racinet authored
- Jun 21, 2020
-
- Jun 22, 2020
-
-
Georges Racinet authored
-
- Jun 21, 2020
-
-
Georges Racinet authored
This is relevant only if the target Mercurial version isn't the one preinstalled in the Dockerfile, which should not happen for released images. Even to install `build-essential`, we need an `apt update` these days, because we're cleaning the lists in the Dockerfile.
-
Georges Racinet authored
We're going to need qualifiers to manage dependencies according to the Python version, and that requires a fairly recent pip/setuptools. The chosen versions are arbitrary: they work well enough for me.
-
Georges Racinet authored
This is the starting point version for Heptapod 0.14
-
Georges Racinet authored
Golang 1.14 will be our main production version, even though Heptapod Workhorse and Shell compile fine with 1.13. Heptapod Shell does not ship any Ruby code any more. Therefore we don't need the cumbersome installation of sources / fix of Ruby scripts for path. Also, the build command is no longer the Ruby script at bin/compile, and the build does not need Ruby at all any more. All of this is driven by upstream changes.
-
- Jun 16, 2020
-
-
Georges Racinet authored
-
- Jun 15, 2020
-
-
Georges Racinet authored
The pip call from install_heptapod would have done it anyway, but that involves reinstalling `build-essential`.
-
Georges Racinet authored
heptapod-shell now has a support branch for 0.13.x, that's where the tag sits.
-
- Jun 11, 2020
-
-
Georges Racinet authored
-
- Jun 10, 2020
-
-
Georges Racinet authored
With heptapod-shell#2, we have Heptapod specific golang code to compile in Heptapod Shell. We are doing the tarball preparation, to feed it to the build image, but we aren't using it to replace the Mercurial clone of Heptapod Shell in the main image. That would probably save us a couple of megabytes in the main image, but we'll probably have to change all of that for Heptapod 0.14 anyway, since there won't be any Ruby code any more, hence no need of sources in the main image for Heptapod Shell.
- Jun 11, 2020
-
-
Georges Racinet authored
-
- May 29, 2020
-
- May 23, 2020
-
-
Georges Racinet authored
-