- Jun 20, 2022
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- Oct 17, 2021
-
-
Georges Racinet authored
This long-running named branch was to carry intrusive changes necessary for operation without any auxiliary Git repository. As of !65, we've reached the point were everything is neatly separated and fully optional, depending on choices made by the other Heptapod components. I have checked as thoroughly as possible that using the `hgitaly2` branch of py-heptapod didn't break anything (unit/integration tests, functional tests).
-
Georges Racinet authored
This is to make sure everything is alright before we merge the hgitaly2 branch into default. (to be ignored in the final merge)
-
- Oct 11, 2021
-
-
Georges Racinet authored
With the progress made in other components since the creation of the hgitaly2 branch, we will now proceed to introduce a NativeStateMaintainer class that won't do any Git conversion.
-
- May 14, 2021
-
-
Georges Racinet authored
-
- May 13, 2021
-
-
Georges Racinet authored
It wouldn't run on the specified hg-git revision anyway. Also, HGitaly is not supposed to depend directly on hg-git, but at most on rewrapped py-heptapod functions, which are supposed to be fully tested (enough to be confident about clear API breakage).
-
Georges Racinet authored
The whole system seems mature enough to do this, and it can provide some early protections if we break the API. If we have serious reasons to regret it, we can still disable it temporarily. (done on the stablest branch so that it will propagate nicely up to default)
-
- May 12, 2021
-
-
Georges Racinet authored
This means that the `.only_py_heptapod_default` now means "and not triggered from upstream hg-git pipelines.
-
Georges Racinet authored
The key is to accept a new variable for the upstream revision. In turn this means that the previous "default" has to be handled in the install script. Since it the existence of a revision was used to decide whether to pull/update, we now have to use a new variable for that.
-
- Mar 11, 2021
-
-
Georges Racinet authored
In particular, no need to include `py3` in them anymore.
-
Georges Racinet authored
Same as done earlier today in HGitaly
-
- Feb 15, 2021
-
-
Georges Racinet authored
We won't need to create a hgitaly2 branch in HGitaly, because the changes are mostly new RPC services, and refactors can be made safely (especially with native projects still considered experimental). On the other hand we needed one in py-heptapod because we're impacting potentially all Mercurial projects. No downstream HGitaly pipeline is configured to work on the hgitaly2 branch of py-heptapod, so it doesn't make sense to trigger anything.
-
- Jan 05, 2021
-
-
Georges Racinet authored
The `BASE_IMAGE_COLLECTION` variable for the pipeling of py-heptapod masks the one defined in the pipeline of HGitaly, which changed with the introduction of the comparison tests with Gitaly. Decided arbitrarily to have the variables in the py-heptapod pipeline as in the HGitaly pipeline. Could have gone the other way.
-
- Dec 04, 2020
-
-
Georges Racinet authored
This matches changes done in the base mercurial image so that its tag is now `default` instead of `latest`. At this point, the CI configuration of py-heptapod can be the same in its `stable` and `default` branches.
-
Georges Racinet authored
We need to use the `stable` tag of the base image for the `hg-current` job. Indeed too bad we can't just propagate the hg branch name, maybe it's time to do something about (uniformity makes the stable branch mergeable into the default branch without fear) It doesn't make much sense to run the `hg-default` and `hg-stable` jobs for the stable branch of py-heptapod, which won't change Mercurial versions, unless hg-stable is for the same hg x.y as hg-current (currently not the case).
-
- Dec 02, 2020
-
-
Georges Racinet authored
For instance, the missing dependency on `attrs` in 1.1.2 would have been detected with this.
-
- Nov 21, 2020
-
-
Georges Racinet authored
The point is to get warned, not to block unrelated development of py-heptapod.
-
Georges Racinet authored
Even though it's fast, it's just not needed to run the same thing many times. Of course it's in the first stage.
-
Georges Racinet authored
I often run it manually anyway and if I forget to do it, it happens frequently that I get a CI failure. The `HEPTAPOD_CI_SKIP_LINT` will be useful to avoid running it more than once.
-
Georges Racinet authored
With more development happening in hg-git right now, it makes sense to check compatibility. This is done by moving the installation of dependencies aside in its own script and make it react to a dedicated environment variable.
-
- Nov 14, 2020
-
-
Georges Racinet authored
This was forgotten in the big refactor of the CI setup. (the tests are currently not passing with hg-default, seems to be quite normal, an API change)
-
- Oct 16, 2020
-
-
Georges Racinet authored
Since py-heptapod also serves as a common library for HGitaly, it makes sense to check the impact of landed changes on HGitaly. This will also propagate scheduler or trigger builds. For example if there's a rebuild of hg-default, it should trigger the rebuild of py-heptapod, which will trigger that of HGitaly. We'll have a few redundant buils along the way (hg-current didn't change in that example), but that's tolerable for the time being and could probably be further optimized.
-
Georges Racinet authored
The install job is expected now to be slower than the other, at least if all Docker images are already downloaded.
-
- Oct 15, 2020
-
-
Georges Racinet authored
-
- Jun 17, 2020
-
-
Georges Racinet authored
with recent (and future) changes in the base images, with pytest for Python3 not necessarily having the '3' in its executable name, this felt necessary: otherwise we'd keep wondering all the time.
-
Georges Racinet authored
-
- May 18, 2020
-
-
Georges Racinet authored
Because Mercurial is loaded through PYTHONPATH, it's not visible to pip (even if we'd set PYTHONPATH for the pip command), therefore that triggers download/build/install of an unrelated Mercurial version.
-
- May 17, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
The common ci-base image will probably not live very long (see octobus/ci-dockerfiles#2), forcing us to make two steps later. We'll see.
-
- May 18, 2020
-
-
Georges Racinet authored
Since we have base images for both, it's quite fast.
-
- May 13, 2020
-
-
Georges Racinet authored
Clearly an oversight after merge from heptapod-0-12 branch. The correct base image has Mercurial 5.4, as Heptapod 0.13 will.
-
- May 09, 2020
-
-
Georges Racinet authored
-
- May 08, 2020
-
-
Georges Racinet authored
In the `default` branch, we'll use a different version.
-
- Apr 30, 2020
-
-
Georges Racinet authored
-
- Apr 19, 2020
-
-
Georges Racinet authored
Up to now, we didn't have Python requirements instead of those that are precisely provided by the build. This series introduces a dependency onto request.
-
- Apr 23, 2020
-
-
Georges Racinet authored
In this branch, we won't care about Mercurial 5.4, for which our tests are broken. The tests broken on the hg stable and default branches have already been fixed in the default branch of this project.
-
- Mar 12, 2020
-
-
Georges Racinet authored
with the upcoming addition of more pytest options, it becomes somewhat necessary to have a single script to avoid duplication in the CI config and some pain for developers. run-all-tests passes all subsequent arguments, allowing to add, e.g., HTML coverage generation options and the like.
-
- Mar 09, 2020
-
-
Georges Racinet authored
The tests are fast enough that a separate lint stage is overkill (it was mostly to try the stage system). However, having compatibility onto future Mercurial and Evolve versions in a second stage is meaningful: these are quite heavier because the dependencies can't be prebuilt, and it doesn't make sense to run them if the main tests don't pass. Install check is also on this second stage, that's again a job that's not expected to fail often but is somewhat heavier, without the dependencies provided by the `ci-py-heptapod` image
-