heptapod-docker merge requestshttps://foss.heptapod.net/heptapod/heptapod-docker/-/merge_requests2019-10-18T17:30:19Zhttps://foss.heptapod.net/heptapod/heptapod-docker/-/merge_requests/2Switching to GitLab 10.2.82019-10-18T17:30:19ZGeorges RacinetSwitching to GitLab 10.2.8Version 0.7.0Georges RacinetGeorges Racinethttps://foss.heptapod.net/heptapod/heptapod-docker/-/merge_requests/1Version-based repo migration and step for restructuration of HGRCs in 0.7.02019-11-11T12:47:22ZGeorges RacinetVersion-based repo migration and step for restructuration of HGRCs in 0.7.0We'll now have a version-based migration system (it's not always possible to know without a version number whether a step has to be done or not), meaning that the `HEPTAPOD_VERSION` file in heptapod/heptapod has to be bumped upon release...We'll now have a version-based migration system (it's not always possible to know without a version number whether a step has to be done or not), meaning that the `HEPTAPOD_VERSION` file in heptapod/heptapod has to be bumped upon release.
We then leverage the new system to rewrite HGRCs according to heptapod#91 and heptapod#103Version 0.7.0Boris FeldBoris Feldhttps://foss.heptapod.net/heptapod/heptapod-docker/-/merge_requests/3Using the non-scanning WSGI application2019-11-19T00:47:52ZGeorges RacinetUsing the non-scanning WSGI applicationThis finishes the work for heptapod#112 by using the non-scanning WSGI application of py-heptapod!1
Since we didn't remove the WSGI wrapper from its current place (`config/mercurial`) in the [Rails application](/heptapod/heptapod], th...This finishes the work for heptapod#112 by using the non-scanning WSGI application of py-heptapod!1
Since we didn't remove the WSGI wrapper from its current place (`config/mercurial`) in the [Rails application](/heptapod/heptapod], this is easy to revert in case of problems.
I'm inclined to try this right away for this week updates (all functional tests do pass for me), so that we can get past this, and have just a last intermediate version before the release of 0.7.0.Version 0.7.0Pierre-Yves DavidPierre-Yves Davidhttps://foss.heptapod.net/heptapod/heptapod-docker/-/merge_requests/4Bump Mercurial to 5.22019-11-20T20:13:20ZGeorges RacinetBump Mercurial to 5.2In Mercurial 5.2, the single-head-per-branch feature ignores
closed head by default, but we still need a patch to make
it easily overridable.
This requires Heptapod's hg-git to include the changes for
hg 5.2 compatibility (merge with hg...In Mercurial 5.2, the single-head-per-branch feature ignores
closed head by default, but we still need a patch to make
it easily overridable.
This requires Heptapod's hg-git to include the changes for
hg 5.2 compatibility (merge with hg-git upstream at 0.8.13)Version 0.7.0https://foss.heptapod.net/heptapod/heptapod-docker/-/merge_requests/6SSH support2019-12-26T11:54:25ZGeorges RacinetSSH supportThis is the wrapping up of developments made for SSH support.
For the time being, it references all relevant topics, but that will fall back to just `heptapod-0-8` once they are merged.
We'll have to add a migration step to remove the ...This is the wrapping up of developments made for SSH support.
For the time being, it references all relevant topics, but that will fall back to just `heptapod-0-8` once they are merged.
We'll have to add a migration step to remove the admin SSH key, this could be in this MR, or in a follow-upVersion 0.8.0https://foss.heptapod.net/heptapod/heptapod-docker/-/merge_requests/8Migrations for Heptapod 0.8.02020-01-08T14:29:33ZGeorges RacinetMigrations for Heptapod 0.8.0These should be executed by the 0.8.0rc2 image.These should be executed by the 0.8.0rc2 image.Version 0.8.0https://foss.heptapod.net/heptapod/heptapod-docker/-/merge_requests/9migrations: writing gitlab-rails/REVISION with Heptapod revision2020-01-14T23:42:18ZGeorges Racinetmigrations: writing gitlab-rails/REVISION with Heptapod revisionThis file is the one whose changes trigger the run of database
migrations at startup. So, for heptapod#159 we need it
to change according to Heptapod revisions, not the mostly
fixed upstream GitLab revisionThis file is the one whose changes trigger the run of database
migrations at startup. So, for heptapod#159 we need it
to change according to Heptapod revisions, not the mostly
fixed upstream GitLab revisionVersion 0.8.0https://foss.heptapod.net/heptapod/heptapod-docker/-/merge_requests/10readme: update links of URLs to foss.heptapod.net2020-02-03T22:40:24ZPaul Morellereadme: update links of URLs to foss.heptapod.netSince heptapod is now hosted on foss.heptapod.net, it makes sense to update
the links in the README.md files.Since heptapod is now hosted on foss.heptapod.net, it makes sense to update
the links in the README.md files.https://foss.heptapod.net/heptapod/heptapod-docker/-/merge_requests/11New Docker tagging policy2020-04-14T21:58:34ZGeorges RacinetNew Docker tagging policyFrom now on, we'll use `testing` tags so that `latest` is always usable. This is what users expect, especially since `latest` is just what they get by default.
This MR for visibility of the change, I've already pushed the `octobus/hepta...From now on, we'll use `testing` tags so that `latest` is always usable. This is what users expect, especially since `latest` is just what they get by default.
This MR for visibility of the change, I've already pushed the `octobus/heptapod:testing` tag and will merge as soon as I need to make a new intermediate image.Heptapod 0.12.1https://foss.heptapod.net/heptapod/heptapod-docker/-/merge_requests/13Reduce image size for Heptapod 0.122020-05-06T11:28:26ZGeorges RacinetReduce image size for Heptapod 0.12This is the previous version of !12, rebased on the heptapod-0-12 branch and now.
Things likes backports in Workhorse and #6 will make us take risks. We might as well lose less time with build and lifting times.This is the previous version of !12, rebased on the heptapod-0-12 branch and now.
Things likes backports in Workhorse and #6 will make us take risks. We might as well lose less time with build and lifting times.Heptapod 0.12.3https://foss.heptapod.net/heptapod/heptapod-docker/-/merge_requests/14Initial base: running apt upgrade2020-05-06T11:28:42ZGeorges RacinetInitial base: running apt upgradeCloses heptapod-docker#6Closes heptapod-docker#6Heptapod 0.12.3https://foss.heptapod.net/heptapod/heptapod-docker/-/merge_requests/12Drastically reduce the main image size2020-09-26T13:17:53ZGeorges RacinetDrastically reduce the main image sizeThis is #5 (which saves us about a whooping GB) followed by more actions: reducing the layers and being more careful with `apt` and `pip`.
Here's the result I get:
```
~/heptapod/docker $ docker image list octobus/heptapod | head -3
R...This is #5 (which saves us about a whooping GB) followed by more actions: reducing the layers and being more careful with `apt` and `pip`.
Here's the result I get:
```
~/heptapod/docker $ docker image list octobus/heptapod | head -3
REPOSITORY TAG IMAGE ID CREATED SIZE
octobus/heptapod testing 5c4d9aadd23b 15 minutes ago 2.02GB
octobus/heptapod 0-12-testing 387afcb08a8a 47 hours ago 3.11GB
```
An interesting metric is the comparison with GitLab base image:
```
~/heptapod/docker $ docker image list gitlab/gitlab-ce | head -3
REPOSITORY TAG IMAGE ID CREATED SIZE
gitlab/gitlab-ce 12.2.12-ce.0 1fe894d81d4f 4 months ago 1.76GB
gitlab/gitlab-ce 12.3.5-ce.0 7783a0d67474 6 months ago 1.77GB
```
These don't change in the lifetime of a Heptapod version, from 0.x.0rc1 to 0.x.y.
In particular, retrieving a freshly built image with my lousy DSL line now completes in less than 2 minutes, given that the GitLab base image is already present.Heptapod 0.13.0https://foss.heptapod.net/heptapod/heptapod-docker/-/merge_requests/15Generating testing-py2 and testing-py3 images2020-05-23T15:24:30ZGeorges RacinetGenerating testing-py2 and testing-py3 imagesThis 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 ch...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](https://launchpad.net/~deadsnakes/+archive/ubuntu/ppa)
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 inadvertently 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.Heptapod 0.13.0https://foss.heptapod.net/heptapod/heptapod-docker/-/merge_requests/16Fixed late build of Mercurial2020-07-22T10:06:16ZGeorges RacinetFixed late build of MercurialThe Mercurial build was failing if the wanted Mercurial version
(from the requirements file shipping with the Rails application)
differs from the one built by `heptapod/assets/heptapod_base_install.sh`.
That is now working.
It is still ...The Mercurial build was failing if the wanted Mercurial version
(from the requirements file shipping with the Rails application)
differs from the one built by `heptapod/assets/heptapod_base_install.sh`.
That is now working.
It is still quicker and leaner if `heptapod_base_install.sh` installs
the right version up front, but it's not strictly necessary. People
doing urgent bugfix builds would not need it.Raphaël GomèsRaphaël Gomèshttps://foss.heptapod.net/heptapod/heptapod-docker/-/merge_requests/17[docker-compose.yml.sample] add log rotation in example deployment2020-09-24T11:09:59ZArthur Lutz[docker-compose.yml.sample] add log rotation in example deploymenthttps://foss.heptapod.net/heptapod/heptapod-docker/-/merge_requests/18Python 3 images: using Mercurial and other Python dependencies from Omnibus2020-09-25T14:22:57ZGeorges RacinetPython 3 images: using Mercurial and other Python dependencies from OmnibusRelies on omnibus-heptapod!3 and saves about 60M in the final imageRelies on omnibus-heptapod!3 and saves about 60M in the final imageHeptapod 0.17.0https://foss.heptapod.net/heptapod/heptapod-docker/-/merge_requests/20push-release: advert overwriting latest image with older series2021-04-02T12:22:18ZGeorges Racinetpush-release: advert overwriting latest image with older seriesThis 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#18This 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#18Georges RacinetGeorges Racinethttps://foss.heptapod.net/heptapod/heptapod-docker/-/merge_requests/21Cleanups and linting2022-01-16T14:37:14ZGeorges RacinetCleanups and lintingAlso for testing of normal operations without any Git inner repo (this project used as an early test of the `:hg_without_git` feature flag)Also for testing of normal operations without any Git inner repo (this project used as an early test of the `:hg_without_git` feature flag)Georges RacinetGeorges Racinethttps://foss.heptapod.net/heptapod/heptapod-docker/-/merge_requests/22pull/push: Verifiyng the ID of the pulled Docker image2022-07-02T08:43:23ZGeorges Racinetpull/push: Verifiyng the ID of the pulled Docker image:rocket::rocket:Georges RacinetGeorges Racinethttps://foss.heptapod.net/heptapod/heptapod-docker/-/merge_requests/19WIP Rely on Omnibus hg-inner-http service2020-10-07T11:49:51ZGeorges RacinetWIP Rely on Omnibus hg-inner-http serviceRelies on work for omnibus-heptapod#10 (not ready yet)
This means we can get rid of our wrapper and various
circumventing things.
What we lose is the ability to run our migration steps, but
we could rehook that one elsewhere if needed ...Relies on work for omnibus-heptapod#10 (not ready yet)
This means we can get rid of our wrapper and various
circumventing things.
What we lose is the ability to run our migration steps, but
we could rehook that one elsewhere if needed (probably we'll
want to adopt the mechanism in some other component before
the eventual decommission of heptapod-docker)Heptapod 0.17.0