- 06 Jul, 2021 4 commits
-
-
Georges Racinet authored
can be useful
-
Georges Racinet authored
The 'development' qualifier only matters for Heptapod Rails, where the release branch is distinct, and that we don't want to be part of this check: the release script will perform the merge if needed instead.
-
Georges Racinet authored
Parenthesis comprehension is just a generator, while list comprehension forces preevaluation.
-
Georges Racinet authored
We just needed a shorter helper.
-
- 05 Jul, 2021 1 commit
-
-
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.
-
- 11 Jun, 2021 2 commits
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- 24 Apr, 2021 2 commits
-
-
Georges Racinet authored
-
Georges Racinet authored
This means in particular that the heptapod branch of the HDK is now the one to manage the three series.
-
- 30 Mar, 2021 1 commit
-
-
Georges Racinet authored
It was previously the default from hg-loggingmod, i.e, /tmp/mercurial.log, with the obvious drawback of mixing logs from several HDK workspaces.
-
- 21 Mar, 2021 1 commit
-
-
Georges Racinet authored
-
- 20 Mar, 2021 2 commits
-
-
Georges Racinet authored
It was meant for personal experiments and can only be a source of confusion in regular times. Will try and use secret changesets in the future for these purposes.
-
Georges Racinet authored
-
- 19 Mar, 2021 2 commits
-
-
Georges Racinet authored
The heptapod branch of the HDK now handles the default and stable Heptapod series. With 0.20 the new stable, none of these has a separate Heptapod Workhorse repo. It is another matter in the `heptapod-stable` branch of the HDK, now dedicated to manage the current oldstable (Heptapod 0.19)
-
Georges Racinet authored
-
- 22 Feb, 2021 2 commits
-
-
Georges Racinet authored
-
Georges Racinet authored
Also stopping to point to the `workhorse-bundled` topic in the `future` series (topic now published). Soon, `future` will point to the HGitaly2 branches.
-
- 16 Mar, 2021 2 commits
-
-
Georges Racinet authored
This is the HDK side of heptapod#440
-
Georges Racinet authored
yes, we should have a small CI definition for linting.
-
- 18 Feb, 2021 2 commits
-
-
Georges Racinet authored
Ideally the rails repo should stay on the corresponding topic until we do the CI enhancement for the bundled workhorse and it gets validated directly by our runners.
-
Georges Racinet authored
See heptapod#402 At this point, upstream GDK has not been modified for the bundled workhorse yet, so we're doing a minimal change on our side, hoping the conflict will be manageable.
-
- 17 Feb, 2021 1 commit
-
-
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
-
- 13 Feb, 2021 1 commit
-
-
Georges Racinet authored
-
- 10 Feb, 2021 6 commits
-
-
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.
-
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.
-
Georges Racinet authored
Must have thought in RST while writing this.
-
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.
-
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).
-
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.
-
- 30 Jan, 2021 5 commits
-
-
Georges Racinet authored
We hope this can help to improve completion times of large functional tests runs on systems with more than four CPUs.
-
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
-
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).
-
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.
-
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.
-
- 11 Jan, 2021 1 commit
-
-
Georges Racinet authored
-
- 17 Jan, 2021 1 commit
-
-
Georges Racinet authored
-
- 11 Jan, 2021 4 commits
-
-
Georges Racinet authored
Improvements in global scripts and documentation
-
Georges Racinet authored
It makes sense to start providing synthetic account of changes.
-
Georges Racinet authored
-
Georges Racinet authored
It is not supported with the HDK.
-