- May 31, 2023
-
-
Georges Racinet authored
This is more convenient than picking the temporary password from `/etc/gitlab`, and can help reproducing CI failures, since the environment variable is used in `heptapod-tests` CI.
-
- May 15, 2023
-
-
Georges Racinet authored
-
Georges Racinet authored
In Docker official terminology, the tag is the whole, e.g., `heptapod/octobus:testing`. In practice, that is a pain.
-
Georges Racinet authored
This is something Docker would do.
-
- Dec 16, 2022
-
-
Georges Racinet authored
-
- Jan 16, 2022
-
-
Georges Racinet authored
-
Georges Racinet authored
This utility used to be about Docker builds in a previous incarnation (and its name was `build-launch`), but that was long ago.
-
Georges Racinet authored
We haven't been using `-dev-` images for more than a year, now.
-
Georges Racinet authored
This constant has no use any more.
-
- 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
-
- 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.
-
- Nov 26, 2020
-
-
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
So, this is only about octobus/heptapod:testing now
-
- 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 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
-
- Jun 22, 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.
-
- May 21, 2020
-
-
Georges Racinet authored
This is done via a new argument in `build-launch` whose value can be `2` or `3`. The default is still `2`, but that could change in a few point releases. A build of the default version will be retagged as `testing`. For Python 3, we chose the Python 3.8 provided by Deadsnakes. There are two other versions currently present in the image: - /usr/bin/python3: standard version from Ubuntu 16.04, too old for Mercurial - /opt/gitlab/embedded/bin/python3: (PATH default) a Python 3.7 that would have been suitable if we had the required headers to compile Mercurial for it. Deadsnakes is a convenient source. Thanks to it, we didn't need to rewrite so much of our base install script (trimming, notably). We decided to avoid the Deadsnake Python 3.7 version so that it's not possible to call inadvertendly the one installed by GitLab (does not have Mercurial nor our libs). That left us with 3.6 and 3.8. Python 3.6 is too close to the minimal version supported by Mercurial (actually 3.6.2), it would have created doubts all along the way. So the winner is Python 3.8, and it's also available for our source installation targets.
-
- May 15, 2020
-
-
Georges Racinet authored
This requires the activation of the experimental features in `/etc/docker/daemon.json`: ``` { "experimental": true } ```
-
- May 03, 2020
-
-
Georges Racinet authored
This means reading `.hg_archival.txt` in there, but that's worth the effort. Remark: Mercurial archives are reproducible enough that Docker would have used its cache. Still, the archival of the Rails app was taking a noticeable time.
-
Georges Racinet authored
For moving target revisions, such as a branch name, we could add a force-update parameter later on.
-
- May 05, 2020
-
-
Georges Racinet authored
At this point we'd be ready to ship backports such as heptapod-workhorse#2. We've always presented Heptapod Workhorse as a tech preview for Heptapod 0.12. That was not only because we weren't ready to package it at the time. For Heptapod 0.12, it would be incompatible with a configuration option that we can't tweak in the Docker image, so we don't COPY it to the final image, but we could do for a suitable backport branch.
-
- May 02, 2020
-
-
Georges Racinet authored
Some source repositories won't be put in the Docker image. A use case is pure Go components, like heptapod-workhorse, which we'll just need to compile outside of the main image (see #4) This could also be useful for #5: we could just untar heptapod-rails on top of the GitLab upstream image
-
- Apr 12, 2020
-
-
Georges Racinet authored
as explained in `build-launch` comment, this would bring more confusion than benefits.
-
- Mar 17, 2020
-
-
Georges Racinet authored
while in ordinary development, it's handy to have the utilities provided by the dev image, in the course of release preparation, it's a huge incentive to do things backwards. Also simply rechecking on the base image was in general too complicated.
-
- Dec 19, 2019
-
-
Georges Racinet authored
The default 2022 port on host is the one expected in `heptapod-tests`
-
Georges Racinet authored
with Heptapod development being more and more branching, it makes sense for the default setup to avoid running 0.6 over volumes meant for 0.7 etc.
-
- Dec 03, 2019
-
-
Georges Racinet authored
-
- Sep 17, 2019
-
-
Georges Racinet authored
-
- Sep 12, 2019
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
It'll be nicer for simulation mode summary
-
Georges Racinet authored
To build and push everything, not running the container in the end would look like ./build-launch --build-base-image --no-run --push We aren't so far from a CI goal that would launch the tests and push only if they do pass.
-
Georges Racinet authored
Helpful if we just want to build
-
Georges Racinet authored
One less hardcoded constant can only help in the long run.
-