- Nov 26, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
Since it's no longer building anything, let's call it just launch. This is now the only useful thing that remains from our former Docker packaging that's obsolete since Heptapod 0.17.0
-
Georges Racinet authored
The builds now happen entirely in Heptapod CI/CD
-
Georges Racinet authored
-
Georges Racinet authored
So, this is only about octobus/heptapod:testing now
-
Georges Racinet authored
CI does not push image release tags
-
- Oct 07, 2020
-
-
Georges Racinet authored
Heptapod Docker images for the future 0.17 version will be produced by Omnibus Heptapod, hence this project has served us well, but is now done. The 0.16 stable images will still be produced by this project, hence we keep the stable branch. Once 0.17 will become the new stable, this project will be made read-only ("archived" in GitLab terminology).
-
- Oct 03, 2020
-
-
Georges Racinet authored
This is transitory, so that we can proceed with our build process transparently, but basically, at this point, we could generate the `testing` and `testing-py3` image directly from Omnibus. If we drop Python 2, we can then simply forget about heptapod-docker (keeping only the stable branch until 0.17 is the new stable series).
-
- Sep 23, 2020
-
-
Georges Racinet authored
In the introduction of the Python 3 images (now the default), we were careful to make a clear distinction between the installation provided by Omnibus and the one for Heptapod (notably Mercurial), in order to create interferences that we couldn't solve for lack of control over the Omnibus install of Python 3. With the introduction of Omnibus Heptapod however, we now have full control. This move saves about 60M in the Python 3 image, and is a step towards not needing any specific installation in the Docker image.
-
- Sep 15, 2020
-
-
Arthur Lutz authored
-
- Sep 22, 2020
-
-
Georges Racinet authored
-
- Sep 21, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Sep 10, 2020
-
-
Georges Racinet authored
In theory, `install_heptapod.py` should be able to reinstall the directl wished version. In pratice that doesn't seem to work any more. As soon as omnibus-heptapod#3 is done, that capability won't much interesting, especially given that Heptapod Docker is on a path to retirement.
-
Georges Racinet authored
This will be the first one relying on the `heptapod/partial` image produced by Omnibus Heptapod
-
- Sep 08, 2020
-
-
Georges Racinet authored
Now that we rely on the "partial" intermediate image, it's vital not to forget to update it, and it makes sense that `--no-cache` would force pulling it. Note that all images pushed to Docker Hub are made with the `build-push-main-images` script, that does pass the `--no-cache` option.
-
- Sep 07, 2020
-
-
Georges Racinet authored
This new `heptapod/partial` base image is built like `gitlab/gitlab-ce`, but has the Heptapod Rails app instead of the upstream Rails app, so we don't need to ADD a tarball for the Rails app any more. As a result, we don't need to specify `heptapod-rails` in `heptapod_revisions.json`, not even to keep a record in the image, because the detailed info in `/RELEASE` is now about Heptapod instead of upstream GitLab. We still need to write REVISION files because Omnibus Heptapod doesn't provide them yet (omnibus-heptapod#8). The Dockerfile sitting here will keep track in version control of the base partial image tag. Closes #10
-
Georges Racinet authored
Keeping only non version related changes
-
- Sep 04, 2020
-
-
Georges Racinet authored
This is nothing but a bump to GitLab 13.1.11
-
Georges Racinet authored
We're now just a few days behind the upstream GitLab image, but it can still happen that some packages get upgraded by our build. In case a conffile thas been earlier tweaked in the upstream build changes in Ubuntu, we don't want the build to abort, and the best course of action is to keep the upstream GitLab version. Such a case just happened to me, with the `base-files` packages and files in `/etc/update-motd.d`.
-
- Aug 30, 2020
-
-
Georges Racinet authored
This will be notablyy the one used by CI for functional tests of the default Heptapod series in the sense of the HDK.
-
Georges Racinet authored
We're using the base image for GitLab 13.3, and this time it's a `ce.1` instead of `ce.0`. We're also preinstalling Mercurial 5.5.
-
Georges Racinet authored
py-heptapod is directly installed typically for intermediate versions that aren't published on PyPI. In some cases (major version change), it can happen that the requirements shipping with the Rails app would be satisfied only by the developement version of py-heptapod. In case of releases, we always have the requirements from the Rails app directly referring a published version on PyPI, and the install script does not install py-heptapod from version control.
-
- Aug 25, 2020
-
-
Georges Racinet authored
Of course, reverting the change of base image name, hence subsequent merges from stable will now conflict on that, and that's a good thing.
-
Georges Racinet authored
Same as done earlier today for the HDK, this is better than version-based stable branches, because the risk of accidentally merging the change of base image name that we are doing for that will get down to almost zero once we've merged it once (and we will immediately).
-
Georges Racinet authored
-
- Aug 24, 2020
-
-
Georges Racinet authored
-
- Aug 22, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- Aug 04, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jul 30, 2020
-
-
Georges Racinet authored
-
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
-