- 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.
-
Georges Racinet authored
This is the minimum so that Mercurial accepts to load it. In turn the heptapod extension is used as an example of how to load an extension in tests in `test_testhelpers`, so this intermediate change is needed to port testhelpers to Python3. Of course we should use another extension, perhaps one shipping with Mercurial so that testhelpers don't depend onto hgext3rd.heptapod any more, but that will be another day.
-
- May 17, 2020
-
-
Georges Racinet authored
Without it, we can't be sure there aren't unicode strings passed to `ui.note()` and the like.
-
Georges Racinet authored
-
- May 18, 2020
-
-
Georges Racinet authored
This will be useful on CI where it can depend how pytest has actually been installed, especially on Python3.
-
- May 16, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- May 19, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
(were actually uncommitted local mods)
-
Georges Racinet authored
The source of truth for the default GitLab branch is the HEAD of the Git repository. If we don't set it, then GitLab will, using a random branch of first push (unless maybe 'master' is among them). Further, it's much simpler and clearer to change from here than from the Rails application, because the latter is mostly meant to perform things like protecting the branch, and isn't really meant to set it to anything other that it's already seeing. For the Rails app, it'll just boil down to clear some caches if the situation looks like HEAD is prone to change (e.g the default branch maps to a topic).
-
- May 18, 2020
-
-
Georges Racinet authored
Before this, neither pre-receive nor post-receive notifications were sent. The former would be a major security concern for upstream GitLab, much less for us, since most of the permission checking is actually done by Mercurial. The latter explains why there aren't pipelines running for tags and why it takes a while for the tags to be visible in the "Run pipeline" page. Closes heptadod#260 What happened here is that the tags were correctly exported and this was tested, but it happened before `update_references()`, which is in particular the method that's responsible for sending notifications. Once the tags were written in the Git repo, of course 'update_references()` wouldn't see them. But it's worse than that: `get_exportable()` only inspects heads (all these methods are really ill-named in hg-git). We considered not duplicating `export_hg_tags()` and comparing the tags before and after, but it has the major drawback for us to write immediately to the Git repo, whereas we want to send the `pre-receive` notification to GitLab before writing. Besides, `export_hg_tags()` wasn't so complicated, and our testing is more thorough than in upstream hg-git.
-
Georges Racinet authored
This is a pristine copy as of hg-git 0.9.0a1
-
- May 14, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- Apr 26, 2020
-
-
Georges Racinet authored
GitLab wikis only read from `master`, and that's pretty hardcoded, down the way to Gitaly, which itself embeds the Gollum library, instead of just providing raw repo content. Since we don't want to fork Gitaly, as long as we are using a Git mirror, it's simpler to tie the `master` and `branch/default` Git branches together in the case of wikis.
-