- Jun 28, 2020
-
-
Georges Racinet authored
See heptapod#311 Subrepos are not needed to update a file, or to perform a merge. In a later version, we could simply neutralize the pull, but then we'd have to make sure that the commit logic is consistent (that's why commits are forbidden separately, too). In current Heptapod, the use of updates is always within shares used for server side operations and mergeability assessment. This change will prevent projects using subrepos to trigger hundreds of pulls that will take too much time, and create resource problems (maybe banning risks even) for hazardeous success anyway.
-
Georges Racinet authored
See heptapod#311 for rationale
-
- Jun 29, 2020
-
-
Georges Racinet authored
We'd still have a long way to go for proper subrepositories support in Heptapod. With this change, at least, we won't get errors because a `.hgsub` file has a `subpaths` section. More precisely, we're using the same config parser as Mercurial does for this file.
-
- Jun 26, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jun 24, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jun 18, 2020
-
-
Georges Racinet authored
Will be useful for convention reuse from HGitaly
-
Georges Racinet authored
The namings are overall heavy (necessary to lift ambiguities due to so many meanings for "branch"), but it should perhaps have been called "parse_gitlab_branch_named_topic" or something.
-
Georges Racinet authored
Until now, we only had constants for the "ref" forms.
-
- Jun 17, 2020
-
-
Georges Racinet authored
The provided `branchmap_branch_from_gitlab_branch()` is not equivalent to the `GitHandler.git_branch_for_branchmap_branch()` method, whose purpose is also to gate invalid new content, and needs a `ui` object for user feedback. When we drop the hg-git conversion, we'll do such validations separately.
-
Georges Racinet authored
The pure bytes-string manipulation functions will need to be cleanly reused from elsewhere, and notably in HGitaly. This is also an opportunity to normalize and explain the terminology.
-
Georges Racinet authored
With the new storage of the default GitLab branch in the Mercurial repository, we need to set it as soon as possible, in preparation for when that's the only thing GitLab will see (instead of the Git HEAD). We need to set it, even if we have to choose a topic or a bookmark for that, and therefore we're doing it also for the Git repository, in order for the information to be consistent. So instead of choosing a named branch only if a previous value randomly chosen by other GitLab component was a topic, we build two sets of candidates, and pick among non named branches only if there's no named branch. The only case where we don't set it is if there are only wild heads *and* the special config item to refuse to choose among them is in place (there would be a "non wild" head otherwise)
-
Georges Racinet authored
This new data is used often by GitLab, sometimes in an indirect way, as a default, that's why it's about the first thing to implement for Mercurial to get native in Heptapod.
-
Georges Racinet authored
This new option was available on the HGitaly side, so we'll need to provide it from here.
-
Georges Racinet authored
This had been done long ago on the HGitaly side, which had actually until recently the only Python 3 version of those test helpers. We're keeping the slightly awkward `return_ctx` though, just changing its default value. The `parent` parameter now accepts both `changectx` instances and binary node ids, so that we don't have to update all the tests that make use of it. Finally, we keep the coverage at 100%, even if launching only the tests of the test helpers.
-
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
-
- Jun 16, 2020
-
-
Georges Racinet authored
That gives us in particular the new post-receive system for prunes.
-
- Jun 15, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jun 14, 2020
-
-
Georges Racinet authored
-
- Jun 10, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jun 13, 2020
-
-
Georges Racinet authored
Closes heptapod#292 File "mercurial/bundlerepo.py", line 481, in makebundlerepository url = b'bundle:%s+%s' % (util.expandpath(repopath), bundlepath) TypeError: %b requires a bytes-like object, or an object that implements __bytes__, not 'str' Not detected by test because `makebundlerepository()` is called only for non-local repositories.
-
- Jun 10, 2020
-
-
Georges Racinet authored
Closes #3
-
- Jun 09, 2020
-
-
Georges Racinet authored
This will make it possible to perform Merge Request detection for branches that are closed in the same push: heptapod#207 We're pruning the GitLab branch right away, which doesn't imped Gitaly from accessing the Git commits for all the changesets involved. To be fair, that's a race with the Git garbage collector, but it's very unlikely we'd have a problem with that on existing instances before we drop Git conversion anyway (Heptapod 0.14)
-
Georges Racinet authored
This makes it more future proof (at this stage it is used for logging only).
-
Georges Racinet authored
Finally the format will be a list of pairs instead of a dict. We provide appropriate serialization avoiding bytes to please JSON and test it.
-
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.
-