- Nov 21, 2020
-
-
Georges Racinet authored
Notably, we don't need the python2/python3 markers, because we don't support Python 2.7 any more
-
- Nov 11, 2020
-
-
Georges Racinet authored
This is typically used with an explicit `branch` keyword argument.
-
Georges Racinet authored
This is the equivalent to `hg rm` for a single file.
-
Georges Racinet authored
it will both be the base for new helpers, and directly usable as demonstrated by the new test case.
-
Georges Racinet authored
it will be used in forthcoming new helpers
-
Georges Racinet authored
it will be useful in forthcoming new helper methods
-
- 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.
-
Georges Racinet authored
Notably in CI, we'll use it to keep checkouts of some live dependencies, such as hg-git.
-
- Nov 19, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
(this is used to test the presence of environment variables, notably for user hooks). The result would be inconsistent between SSH and HTTP access. Another solution would be to add the variable to the HTTP case (forwarding in WSGI wrapper), but that's an implementation detail for real consumers, so we did not.
-
Georges Racinet authored
All operations performed on the Rails app work within a temporary share. Therefore, if users create their first changeset from the web app, we have to set the default GitLab branch in the actual repository.
-
- Nov 18, 2020
-
-
Georges Racinet authored
Instead of ignoring the prune (and hence making a slight discrepancy between Git and Mercurial content), we will refuse the transaction. Someone with enough commit rights to close the default branch can surely change it in the Heptapod project settings. This is ultimately because the native mode reads Mercurial content only. Of course, when it doesn't perform Git conversion, we'll still have to port that check, but the functional tests are also covering this, so we'll know.
-
Georges Racinet authored
As explained in the doctest, this is very unwanted. Up to now we were just removing that prune at the end of the process. With the native mode (currently still using hg-git) we can't do that any more: we will need instead to abort the transaction if there is such a scheduled prune (mostly for other reasons, such as closed heads). Therefore the simplest here is to not schedule the prune.
-
Georges Racinet authored
We split out the filtering logic and (GitLab) branch prune scheduling related to masking by bookmaks, before we add more rules to it, without changing any outcome for now. This is also an opportunity to clarify the comments and move them up the ladder: it's always nicer as a docstring.
-
Georges Racinet authored
This is a simple refactor, but we take the opportunity to explain the difference with the "default GitLab branch" of native repositories: they're stored differently, should be equal wherever it makes sense (it won't when native repositories won't use hg-git except for mirroring).
-
Georges Racinet authored
This puts it in conformity with its docstring. Actually the Rails app doesn't make anything of it at this point, but this was done along the way.
-
- Nov 17, 2020
-
-
Georges Racinet authored
-
- Nov 16, 2020
-
-
Georges Racinet authored
Part of heptapod#368: the Rails app will be able to set this environment variable and we're now sending it back as the `accept_mr_iid` key to the listener for the pre-receive hook, so that the Rails app may apply merge permissions instead of (direct) push permissions. Using the (project-local) iid is better than the id, because the receiving end won't have to check that someone is trying to cheat with a MR on another project and is anyway fast compared to the overall amount of process on its side.
-
- Nov 15, 2020
-
-
Georges Racinet authored
This is part of heptapod#364. Heptapod Workhorse will pass the `X-HEPTAPOD-HG-NATIVE` header with the appropriate value, and we use it to set configuration on the wished repository accordingly. We could have made the `env` argument of the `load_repo()` method optional (and hence hadn't needed to adapt existing tests), but nothing would then prove that it wasn't forgotten, even with coverage proving that `load_repo()` is indeed called (which it does).
-
Georges Racinet authored
This is part of heptapod#364. Heptapod Shell cannot pass `--config` command-line arguments, because that is rightfully considered a potential security breach (it would allow to register a hook, hence for arbitrary code execution). So we resort to an environment variable. It will actually also be more practical for the Rails app (only one method, the env creator, to patch)
-
- Nov 14, 2020
-
-
Georges Racinet authored
This is the first part of heptapod#364 If the new `heptapod.native` config flag is set, payloads of GitLab hooks will be made of Mercurial SHAs instead of Git SHAs. This will be used for native Mercurial projects, for which obviously GitLab notification hooks must contain Mercurial SHAs, since these are the only ones the Rails app is supposed to be aware of. For now, there's no facility to set this flag automatically but it can be used for testing in developer setups (by putting it in `hdk.hgrc`). ## Implementation details: Instead of going over all the places were a SHA is recorded that will end up in a hook call, we convert back to Mercurial right before we send the hook. This is perhaps good enough, while we are in the transitional way of operation of still converting to Git. Things will be very different anyway when we don't do that any more.
-
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)
-
- Nov 10, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- Nov 01, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
That was long overdue
-
Georges Racinet authored
See also heptapod#352
-
- Oct 26, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- 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
-
- Oct 14, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- Sep 30, 2020
-
-
Georges Racinet authored
In particular this brings the enforcement of the 100% coverage policy.
-