- Jun 09, 2020
-
-
Georges Racinet authored
In some future, perhaps without hg-git, we may want not to represent prunings also in changes. If that happens, we'll still want GitLab to learn about them.
-
Georges Racinet authored
This was left as TODO in the introduction of HeadPruneReasons: the analysis method is the one that has all information to distinguish cases. Before we sent precise prune reasons to GitLab we had no other choice than setting the new Git SHA, which was obviously artificial for a vanished topic. We still have some cases where we won't tell GitLab anything, though.
-
- Jun 08, 2020
-
-
Georges Racinet authored
We need to serialize the hg_prune field itself as JSON, since the GitLab internal API would accept only plain string as values on the other side (or we'd have to go to great length with the `Hash` param type to produce the flexibility we need). GitLab branch names are received as bytes and output as base64 in the resulting payload, leaving the burden to guess the encoding to the Rails application. This is less cowardly as it sounds: on the Rails side, there's already a layer of decoding and encoding guesswork for the `changes` parameter (identical to a Git post-receive stdin payload). Hence, we'll be able to use the same system for consistent results.
-
- Jun 07, 2020
-
-
Georges Racinet authored
The request firing and first error treatments are now done in the base Hook class, thanks to the new 'api_endpoint` class attribute.
-
Georges Racinet authored
Part of heptapod#269 The prune reasons are given as a dict mapping GitLab branch names to `HeadPruneReason` instances. At this point the `gitlab.hooks.PostReceive` class will just ignore the prune reasons, the next move will be to send them alongside the usual changes (now called `git_changes`) to the new API endpoint. This is almost compatible with the previous operation, except that merge request detection wouldn't work for topics, since we're pruning them right away and we don't have the new GitLab logic yet. No details are provided for closed branches, but we have the infrastructure to do so.
-
Georges Racinet authored
The design dated back to the time when the Hook class was merely a wrapper to call external executables provided by GitLab, whose file name was actually `self.name`. It's much clearer to specialize them in the `PreReceive` and `PostReceive` classes. On the `hgext3rd.heptapod.git` side, we had the `_gl_repos` attribute to avoid multiple instantiations (dating back from the triple inner push era) and everything was also string oriented. It's much simpler and no less efficient to instantiate the proper hooks in `heptapod_apply_changes`.
-
Georges Racinet authored
The idea is that we are going to develop a "post-receive" hook to pass additional Mercurial information to GitLab. This new hook and its supporting data classes should survive the move to native Mercurial, hence `heptapod.gitlab` should be the right place to put them. It would be tempting to use `attrs` for these simple data classes, and maybe we will. For now, let's just not add dependencies.
-
- Jun 08, 2020
-
-
Georges Racinet authored
Apparently, the recently released dulwich 0.20 requires Python 3
-
Georges Racinet authored
-
Georges Racinet authored
I was glad not to see the stupidest of all rules any more, turns out that was only because we were running an old version of flake8. In a nutshell, this rule is harmful, line breaks before binary *boolean* operators are useful for clarity. I've grumpily tolerated this rule in the past on new codebases. Won't waste time on it for an existing code base because of a linter version change.
-
Georges Racinet authored
We're using 'l' as identifier only when there's no ambiguity (very short-lived loop where it essentially doesn't matter and can't be confused with '1' in context)
-
- Jun 07, 2020
-
-
Georges Racinet authored
We're going to add more in the `heptapod.gitlab` package
-
- May 28, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- May 27, 2020
-
-
Georges Racinet authored
This will help with heptapod#278 and anything that gives rise to doubts as to what's exactly sent.
-
- May 23, 2020
-
-
Georges Racinet authored
-
- May 22, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
Previously, it was actually expecting the current working directory to be in a Mercurial repository, which works only coincidentally on Heptapod source installations made from a repo.
-
Georges Racinet authored
Testing that a branch name encoded in iso-latin-1 is presented as-is to Git.
-
- May 21, 2020
-
-
Georges Racinet authored
It's cool to write tests, it's better to have assertions.
-
Georges Racinet authored
`ui.write()` expects bytes, but we were feeding `str`. Of course wasn't catched by our tests, since they rely on patching `ui.write()`
-
Georges Racinet authored
and that means we have to fix for py3.
-
- May 15, 2020
-
-
Georges Racinet authored
main use case: displaying detailed version info in the Rails UI (heptapod#199, heptapod#271) - the information we need - as JSON, since parsing that is a solved problem
-
- 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 17, 2020
-
-
Georges Racinet authored
While we have plans to remove the auxiliary Git mirror repository used to expose content to the web app as soon as in Heptapod 0.14, we know that this won't be possible before a longer time for the repositories backing the wikis. Also this allows us to test with python3 earlier, and it's not completely excluded that 0.14 could support both Python 2 and Python 3. As a side note, the difference in representation of bytes string between the two Python versions force us to resort to assertions with poor style in doctests. We'll live with that.
-
- May 16, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
The declarations for these booleans were already spelled as bytes.
-
Georges Racinet authored
Actually, only the tests needed to be ported.
-
Georges Racinet authored
To recall, this patch gives limited access (as system environment variables) to ui.environ (can be from WSGI)
-
- May 20, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
This forced us to clean up the situation with HTTP error responses. - the status line now conforms to the common practice (no user level message) - the body (error details) is normalized to UTF-8. This gives us simpler code paths and the odds of outputting garbage are very low (complete assessment in the comment, keep in mind that we'll be supporting python2 for one or two months at most in Heptapod).
-
Georges Racinet authored
In the case of `gitlab-mirror`, at this point the underlying command from `hgext3rd.heptapod` is not ported.
-
- May 17, 2020
-
-
Georges Racinet authored
This was on Python2 neatly solved by using `repr()` or `%r` now we have to do it on our side.
-
- May 16, 2020
-
-
Georges Racinet authored
GitLab filesystem paths are enforced to be ASCII, see `app/validators/project_path_validator.rb` and `lib/gitlab/path_regex.rb`. The paradigm here is that output sent back to the caller will have to be as bytes, since we'll be in Mercurial code. The `format_` functions all take unicode strings as input, so that alignments are less wrong than with bytes. Mostly all of this is ASCII anyway at this point, but it doesn't harm to be somewhat ready for i18n in push messages. Overall, we prefer to have occasional `?` replacement marks rather than failed pushes (these can be business critical for our users).
-
- May 20, 2020
-
-
Georges Racinet authored
The conventions about incoming strings had to be made explicit, which led us to initiate a proper docstring for `LocalRepoWrapper`. Of course that doesn't mean that the convention is perfectly respected, but it can be considered a specification. We already have at least one case that needs conversions, to be handled when the need arises.
-