- Dec 23, 2024
-
-
Georges Racinet authored
-
- Nov 19, 2024
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- Oct 17, 2024
-
-
Georges Racinet authored
and of course we need a the `future` image tag.
-
Georges Racinet authored
The merge of stable into default of fd834b00db15 is the culprit.
-
- Sep 14, 2024
-
-
Georges Racinet authored
In this case we went ahead and created it in advance. It is perhaps a scheduling hazard in the New Cycle procedure, though.
-
Georges Racinet authored
-
- Sep 03, 2024
-
-
Georges Racinet authored
With `heptapod/heptapod@078f7f4a040f` now merged in Heptapod, the actual versions used upstream are available and included in the CI/CD configuration file, so we can pass them. This effectively updates several components, notably Git 2.36 -> 2.45
-
- Sep 02, 2024
-
-
Georges Racinet authored
This matches what upstream does in heptapod/heptapod@078f7f4a040f. For now we are simply aiming for an indentical result and cannot yet expose in `kaniko.sh`, as the above cited changeset is not merged yet.
-
Georges Racinet authored
This will be easier to compare with `version.yml` from the Rails app.
-
Georges Racinet authored
This brings in the usage of `.gitlab/ci/version.yml` from heptapod/heptapod>
-
- Aug 18, 2024
-
-
Georges Racinet authored
Ultimately, this `.gitlab/ci/version.yml` coming from upstream GitLab, hence giving us automatic upgrades. Also, they apparently switched ruby from `3.1.patched` to `3.1.5` (maybe a patch went to upstream Ruby).
-
- Aug 08, 2024
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jul 23, 2024
-
-
Georges Racinet authored
This is the simplest way to have the Rails pipeline work on it. The procedure for Mercurial bumps already states to revert the effect by rebuilding the head of named branch in case of rollback. This is not entirely satisfactory (it would be nicer to pass over the appropriate changeset id), but it is good enough for now. Rollbacks are in practice uncommon.
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
It is now expected that only the variable `RAILS_BRANCH` will differ in `stable` and `oldstable` branches. However it is much better to perform Mercurial version bumps on the default branch (before branching Heptapod), because otherwise that would need the topic to exist both on developement and release branches of the Rails app.
-
- Jul 09, 2024
-
-
Georges Racinet authored
It should not matter, but we need to rebuild anyway
-
- May 24, 2024
-
-
Georges Racinet authored
-
- Apr 29, 2024
-
-
Georges Racinet authored
It has now become necessary, as Workhorse won't build on 1.20 (needed for the RSpec runs).
-
- Apr 19, 2024
-
-
Georges Racinet authored
-
- Mar 17, 2024
-
-
Georges Racinet authored
-
Georges Racinet authored
In the same move, upstream made the OS itself configurable, still using Debian by default, so we enclose OS and version in one single variable (they use two separate ones). Also bumped `CHROME_VERSION` to 120 because the combination with version 113 does not exist with bookworm (should actually have been done earlier, but we don't use Chrome in CI for Heptapod)
-
- Mar 14, 2024
-
-
Georges Racinet authored
-
- Mar 01, 2024
-
-
Georges Racinet authored
The default Ruby version for CI was bumped between GitLab v16.7 and 16.8 to 3.1 (see heptapod@e2ed41d6e250). While 3.0 is still supported (as `old_ruby`), it is not tested in all pipelines and can therefore be overlooked. An example is https://foss.heptapod.net/heptapod/heptapod/-/pipelines/78174/ (the `intersect?` method for arrays got introduced in Ruby 3.1). This likely leads to later reverts (happened in the example above), but investigating these is a waste of time and energy in Heptapod development.
-
- Jan 20, 2024
-
-
Georges Racinet authored
-
- Jan 18, 2024
-
-
Georges Racinet authored
The only change is Rust version, and that should be helpful, since Mercurial's MSRV is due to change soon.
-
Georges Racinet authored
But keep using development branch of main repo in `install_pythonlibs`
-
- Jan 07, 2024
-
-
Georges Racinet authored
Now that the release branch also has Mercurial 6.6 in its requirement files, we can do it.
-
- Jan 06, 2024
-
-
Georges Racinet authored
-
- Dec 12, 2023
-
-
Georges Racinet authored
-
- Dec 16, 2023
-
-
Georges Racinet authored
What triggers the change is that Go 1.20 becomes necessary between Gitaly 56ab62b8e3cf853560e2417fe239219c51f0b228 and 357e09f248881f0461a5ec8989ca01ccd9b2a860. We match other versions, so that the precise combination does exist upstream.
-
- Dec 12, 2023
-
-
Georges Racinet authored
-
- Nov 24, 2023
-
-
Georges Racinet authored
(fixed assets/install_pythonlibs so that it does not point to `heptapod-stable` branch of the Rails app)
-
- Nov 20, 2023
-
-
Georges Racinet authored
Also fix the base revision: using branch/heptapod was plain wrong. This has to be followed by a change to heptapod-0-40 once the branch is created, and this subtlety should make its way in the future procedure for cutting out a release branch.
-
- Nov 17, 2023
-
-
Georges Racinet authored
For CI purposes, downloading the prebuilt binary is good enough. It will be available in /usr/local/bin, hoping that is on PATH for all jobs.
-
- Nov 13, 2023
-
-
Georges Racinet authored
-
- Oct 08, 2023
-
-
Georges Racinet authored
This parallels heptapod/heptapod@7a3f8462174b (GitLab 16.1 development cycle)
-
Georges Racinet authored
and make it simpler to maintain, with its own build argument. This, too, should have been done earlier (GitLab 15.10) and is needed for upstream v16.1 because there is no other option with node 18.16
-