- Jan 13, 2022
-
-
Georges Racinet authored
This is a good uniformity move.
-
Georges Racinet authored
-
- Jun 21, 2021
-
-
Georges Racinet authored
This script does not build (even less push) images anymore. Since its only purpose is to run the container, the `--no-run` option has also become irrelevant.
-
Georges Racinet authored
The logic was based on branches on the present repository, which does not make much sense anymore. This led us also to remove the base/dev image tag dichotomy and related options and feedback.
-
Georges Racinet authored
-
- May 27, 2021
-
-
Georges Racinet authored
Nowadays, the Docker images are produced by a pipeline with a Docker tag based on the Mercurial changeset ID in omnibus-heptapod, on top of the `testing` tag. The subsequent heptapod-tests pipeline uses the image with the precise changeset ID. The new `--verify-hg-tag` resolves the expected changeset ID from tag and perform the comparison of images, to make sure that the `testing` image is the one the functional tests ran against.
-
Georges Racinet authored
Nothing was displaying the actual calls to `docker pull`, which does not repeat its arguments, only the outcomes. Using `logging` makes it clear that it's output from the script, not from Docker or any other subprocess.
-
- Apr 02, 2021
-
-
Georges Racinet authored
The tilda is the Debian package convention, we don't have that in the actual Heptapod version name.
-
- Mar 20, 2021
-
-
Georges Racinet authored
This make the `series` parameter mandatory It was far too easy to forget it, hence to overwrite the `latest` image on Docker Hub, as experienced yesterday, see omnibus-heptapod#18
-
- Mar 08, 2021
-
-
Georges Racinet authored
could be really weird if something got wrong in Omnibus package version logic. Also an opportunity to display the build number for human operator alert if it's unexpected
-
Georges Racinet authored
Previous change in `read_versions` function was minimal, but with only one image it's become a convoluted way of doing. That function has become useless
-
Georges Racinet authored
Since we dropped Python 2, we only have one testing image for each series.
-
- Feb 08, 2021
-
-
Georges Racinet authored
- preparation of source doesn't make sense any more, since we're not building anything - pushing Docker images not the responsibility of this script.
-
Georges Racinet authored
This needed to introduce more flexibility.
-
- Dec 15, 2020
-
-
Georges Racinet authored
…and rewritten in Python for safe command line arguments parsing.
-
- Dec 03, 2020
-
-
Georges Racinet authored
It was pulling from Heptapod registry with tag 'latest'. Naming didn't account for the fact that it pushes to Docker Hub
-
- Nov 26, 2020
-
-
Georges Racinet authored
This one was a source of confusion.
-
Georges Racinet authored
-
Georges Racinet authored
-
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
- 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`.
-