This instance was upgraded to Heptapod 0.31.0 (final) today.

  1. 06 Jul, 2021 4 commits
  2. 05 Jul, 2021 1 commit
    • Georges Racinet's avatar
      release script: starting point with clean rev checks · a6c326b38630
      Georges Racinet authored
      Having the release script within the HDK has an important
      advantage: the HDK series gives us knowledge of the current
      development branch for any given release branch
      
      For now, focuses on checks but that's already quite useful.
      a6c326b38630
  3. 11 Jun, 2021 2 commits
  4. 24 Apr, 2021 2 commits
  5. 30 Mar, 2021 1 commit
  6. 21 Mar, 2021 1 commit
  7. 20 Mar, 2021 2 commits
  8. 19 Mar, 2021 2 commits
  9. 22 Feb, 2021 2 commits
  10. 16 Mar, 2021 2 commits
  11. 18 Feb, 2021 2 commits
  12. 17 Feb, 2021 1 commit
    • Georges Racinet's avatar
      Bumped heptapod-stable branch · 94a2124dcd37
      Georges Racinet authored
      With the forthcoming 0.20 having important structural changes
      (bundling of Workhorse), we'll gonna need a separate stable branch
      for the HDK in this development cycle
      94a2124dcd37
  13. 13 Feb, 2021 1 commit
  14. 10 Feb, 2021 6 commits
    • Georges Racinet's avatar
      Release series: heptapod-switch-new-stable and documentation · bd215f39ec2b
      Georges Racinet authored
      Now that the names of release series are fixed, we can use them
      in the heptapod-switch-new-stable script, making the development
      cycle idea more that a feeling.
      
      The case of release HDK workspaces wasn't documented at all until
      now.
      bd215f39ec2b
    • Georges Racinet's avatar
      doc: explained the development cycle idea · 8ef0e15ac7e9
      Georges Racinet authored
      So we now have cycles (Heptapod 0.18), series (stable) and
      branches.
      
      The doc is rewritten for emphasis on how a HDK workspace typically
      starts on the default series, then moves on to stable, and can
      eventually die out.
      
      If at some point we extend the (currently very short) support time,
      we could add, to paraphrase Debian, `oldstable` and even `oldoldstable`
      or someone would come with better namings.
      8ef0e15ac7e9
    • Georges Racinet's avatar
      doc: fixed blockquote · c5e9cb4f8d75
      Georges Racinet authored
      Must have thought in RST while writing this.
      c5e9cb4f8d75
    • Georges Racinet's avatar
      doc: mention `gdk help` and shorten its output · 90a6fecf03db
      Georges Racinet authored
      The shortening prevents the doc to become out of sync, even
      if it doesn't matter much.
      
      `gdk help` is really useful.
      90a6fecf03db
    • Georges Racinet's avatar
      heptapod-switch-new-stable: easier to adapt HDK branch check · ad6c89e36edd
      Georges Racinet authored
      Unless when there are major structural changes in the project
      (such as the upcoming bundling of Workhorse into the main repo,
      see #402), we prefer not to have several branches of the HDK
      itself.
      
      This changes makes it simple to change the checked branch
      (also not that when it goes from heptapod-stable to heptapod,
      the user will probably really need to update).
      ad6c89e36edd
    • Georges Racinet's avatar
      Release series: a more permanent feeling · cedbe23914ce
      Georges Racinet authored
      Instead of 0.18, 0.19 etc for release series, we'll now have
      `release` and `release-stable`, which of course will keep on
      pointing to the appropriate branch of the Rails application.
      
      This helps thinking of a HDK workspace (be it for development
      or release) as supporting an entire development cycle.
      cedbe23914ce
  15. 30 Jan, 2021 5 commits
    • Georges Racinet's avatar
      Rails: made number of Puma workers configurable · e2c370d63c58
      Georges Racinet authored
      We hope this can help to improve completion times of
      large functional tests runs on systems with more than
      four CPUs.
      e2c370d63c58
    • Georges Racinet's avatar
      heptapod-tests: using `hdk` tox testenv, configurable Python · f9968cc0f88b
      Georges Racinet authored
      The Python interpreter used to launch the functional tests (used
      by tox as base Python to create its virtualenvs) is now
      independently configurable. It defaults to the version used
      for Heptapod Python components.
      
      This depends on the landing of the `testenv:hdk` section of
      `tox.ini` in heptapod-tests
      f9968cc0f88b
    • Georges Racinet's avatar
      Python: made interpreter configurable. · 6a37de9cf9c9
      Georges Racinet authored
      Heptapod supports Python 3.7 and 3.8, with 3.9 working but
      not officially supported yet: the official builds currently
      include Python 3.8.7
      
      Debian buster ships Python 3.7
      In Fedora 33, the python3 package is 3.9, yet there is a separate
      python3.8 package for development purposes (that's us!).
      
      Of course, people may want to use any interpreter, whence the
      `python:interpreter` setting.
      
      Warning: The HDK virtualenv is *not* updated upon change of interpreter
      (it could be done later if needed).
      6a37de9cf9c9
    • Georges Racinet's avatar
      Python: created settings section, moved `virtualenv` there · 25adafde5461
      Georges Racinet authored
      The `virtualenv` config setting specifies the path to the
      virtualenv managed by the HDK (where Mercurial and our Python
      code is installed).
      
      Before this change, the setting was not consistent, used as a
      shortcut for what was hardcoded in the Makefile: changing it would
      have just created wrong configuration files.
      
      Now the setting is applied by the Makefile, and we take the
      opportunity to move it in a new `python` section, which was
      our original motivation.
      25adafde5461
    • Georges Racinet's avatar
      Rails: made number of background workers configurable · b5d455893e66
      Georges Racinet authored
      Heptapod functional tests are heavy on the actions that involve
      background jobs: imports, deletion and of course merge requests
      and pipeline related tests.
      
      It's mildly surprising that upstream GitLab does not already provide
      such a facility.
      b5d455893e66
  16. 11 Jan, 2021 1 commit
  17. 17 Jan, 2021 1 commit
  18. 11 Jan, 2021 4 commits