Skip to content
Snippets Groups Projects
  1. May 31, 2023
    • Georges Racinet's avatar
      launch: new `--root-password` option · cb4e2f8828a4
      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.
      cb4e2f8828a4
  2. May 15, 2023
  3. Dec 16, 2022
  4. Jan 16, 2022
  5. Jun 21, 2021
  6. Feb 08, 2021
  7. Nov 26, 2020
  8. Oct 03, 2020
    • Georges Racinet's avatar
      build-launch(py3): do not build base image, just retag "partial" · 93d758ccf758
      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).
      93d758ccf758
  9. Sep 23, 2020
    • Georges Racinet's avatar
      Using Python 3 and packages (Mercurial) from heptapod/partial image · abdec64b329f
      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.
      abdec64b329f
  10. Sep 08, 2020
    • Georges Racinet's avatar
      build-launch: --no-cache option refreshes base images · adedc2432cff
      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.
      adedc2432cff
  11. Sep 07, 2020
    • Georges Racinet's avatar
      Using the partial image produced by Omnibus Heptapod · 3b3c1f2e064e
      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
      3b3c1f2e064e
  12. Jun 22, 2020
  13. Jun 10, 2020
    • Georges Racinet's avatar
      Golang build for Heptapod Shell · 78a579b31a71
      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.
      78a579b31a71
  14. May 21, 2020
    • Georges Racinet's avatar
      Generating testing-py2 and testing-py3 images · 80fed697398d
      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.
      80fed697398d
  15. May 15, 2020
  16. May 03, 2020
  17. May 05, 2020
    • Georges Racinet's avatar
      Grafted workhorse build from default branch, not using it · fac255a3d0f2
      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.
      fac255a3d0f2
  18. May 02, 2020
    • Georges Racinet's avatar
      build-launch: ability to prefetch and tar sources · 93a63dd4c26f
      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
      93a63dd4c26f
  19. Apr 12, 2020
  20. Mar 17, 2020
  21. Dec 19, 2019
  22. Dec 03, 2019
  23. Sep 17, 2019
  24. Sep 12, 2019
Loading