- May 13, 2020
-
-
Georges Racinet authored
On Mercurial 5.2, there was no official compatible version yet. We were using tags put in the legacy Heptapod fork of hg-git. The freshly released hg-git 0.9.0a1 is compatible all the way up to Mercurial 5.4
-
- May 09, 2020
-
-
Georges Racinet authored
-
- May 08, 2020
-
-
Georges Racinet authored
In the `default` branch, we'll use a different version.
-
- May 06, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
As of hg-evolve 9.3.1, some obsolete heads are ignored in the protection agains multiple heads. These happen typically in stacked topic scenarios, after amendment of the anterior topic. These should not count as multiple heads in our exposition to GitLab either, we're applying the same function to filter them out. This has us convert systematically to changeset contexts (standard abbrev being `ctx`) whereas we were doing so before only in the loop to ignore closed branches.
-
- May 05, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
For the call to `published_topic_latest_hg_sha` in the case the previous changeset is obsoleted by a public changeset, since we now get `None` if the successor is not on topic, we can avoid checking that condition in advance, to test the `None` return value explicitely without creating dead code. Using a revset for that will be marginally slower.
-
Georges Racinet authored
This condition was an indication of corruption, but refusing the push currently does much more harm than cleaning up the condition, even if the cleanup risks itself to turn out wrong. In the case detailed in heptapod#265, we had a Git repository inconsistency which we could only reproduce manually by forcing the Git branch for the topic: the previously know topic head was both public and not on topic. Getting `None` in the other call to `published_topic_latest_hg_sha` can't happen, but this will have to be refactored for clarity.
-
- May 03, 2020
-
-
Georges Racinet authored
We're going to need to send GitLab hooks from the temporary working directories (shares) that are used in Rails to perform operations. For that, the path to the Git repo must be inferred from the share source path.
-
- Apr 26, 2020
-
-
Georges Racinet authored
We make `GL_REPOSITORY` the norm to describe the repo in GitLab terms: - in `wsgi.py`, we now expect to receive it from Heptapod Workhorse, matching changes done there right after the merge with the version for GitLab 12.3.5. In the subprocess call case (gitlab-shell or Rails app), we already had it. - instead of hardcoding `project-$id` to pass it to GitLab API endpoints, which was too restrictive, we just repass it over - we still produce a `HEPTAPOD_PROJECT_ID` environment variable for external Mercurial hooks, but now we derive it from GL_REPOSITORY
-
- Apr 30, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Apr 29, 2020
-
-
Georges Racinet authored
This will be useful for rebase and fold operations from the Rails app. As explained in the docstring, the same result can be obtained with two successive calls to hg log, together with parsing of results to refuse ambiguities. While such a upstream Mercurial or Evolve should provide a template for this, we'll have a much better robustness with this fully tested command. Making the call from Rails the simplest possible has the biggest value for us.
-
Georges Racinet authored
It will also be useful elsewhere
-
- Apr 25, 2020
-
-
Georges Racinet authored
The API JSON payload for the post-receive endpoint has changed: messages categorization is simpler (`basic` or `alert`) and they are preformatted. We still support the GitLab 12.2 style
-
- Apr 26, 2020
-
-
Georges Racinet authored
It's been introduced in a9f1a24b9679, with the post-receive hook as a direct API call implementation (not in a any relased version)
-
- Apr 24, 2020
-
-
Georges Racinet authored
-
- Apr 20, 2020
-
-
Georges Racinet authored
The returned message is very generic, but the exact cause will be ovious in the logs. Most immediate case is misconfiguration.
-
Georges Racinet authored
Some libraries have to be excluded from the `demandimport` mechanism, because the requests library has conditional imports and checks and them. There wasn't any problem with these in early tests, all conducted in HTTP context: probably gunicorn did an earlier, regular import. But through SSH, which spawns a `hg` subprocess directly, the problem is immediate.
-
- Apr 19, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
Some existing Heptapod instances will benefit from their configuration being compatible with 0.13
-
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.
-
- Mar 10, 2020
-
-
Georges Racinet authored
This implements the `post-receive` hook by a direct HTTP call to the internal API endpoint. For this, two new config parameters in the `heptapod` section are introduced: - gitlab-internal-api-secret-file - gitlab-internal-api-url We're keeping the previous structure, with a `name` that's now almost useless and leads us to the complication of the `_hook_methods` dict. This keeps compatibility for the caller (also part of this package since Heptapod 0.12), allowing us to refactor in a separate step.
-
- 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.
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Feb 17, 2020
-
-
Georges Racinet authored
The easiest part of heptapod#189: since the extension is inert if there is no manifest file, activating it inconditionally won't be a problem.
-
- Apr 20, 2020
-
-
Georges Racinet authored
The structure of the `phases` transaction attribute has changed. It's now a list of (key, value) pairs instead of a dict, and keys are lazy ranges (`xrange` in Python2) of revision numbers. The new unit test doesn't prove it really works for a given Mercurial version, only a separate run will do that, but it'll help developers work on both versions at once if they need to change the logic.
-
- Mar 27, 2020
-
-
Georges Racinet authored
In Mercurial 5.3, `source` and `base` are single valued, hence just a string, whereas in current default branch, future 5.4, they become lists. We could fix that by version introspection, but in that case, we're rebasing a topic with a single changeset, so that switching to the implicit form, or `rev`, which is already expected to be a list should work for both versions.
-
- Apr 20, 2020
-
-
Georges Racinet authored
-
- Apr 18, 2020
-
-
Georges Racinet authored
-
- Apr 05, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-