- Dec 02, 2020
-
-
Georges Racinet authored
Not actually needed in the most common cases… until it is!
-
Sushil Khanchi authored
-
- Dec 15, 2020
-
-
Georges Racinet authored
-
- Dec 14, 2020
-
-
Georges Racinet authored
-
- Dec 13, 2020
-
-
Georges Racinet authored
-
- Dec 06, 2020
-
-
Georges Racinet authored
There does not seem to be any change on the service method that are currently implemented in HGitaly.
-
- Dec 14, 2020
-
-
Georges Racinet authored
Not the first time I see grpc being tolerant with an empty response having the wrong type.
-
- Dec 06, 2020
-
-
Georges Racinet authored
While it sounds like a good idea to to register the handler even before the workers started, this actually has them inheriting it and mask the one installed by Mercurial. So currently, we theoretically still have a race: if the main process gets a SIGTERM before registration, there could already be some workers, to which it wouldn't be propagated.
-
Georges Racinet authored
Reminder: we can't yet do multiprocessing for Unix Domain sockets. The startup code had already only the first worker listen to them. But it's fairly common that there are no addition tcp URLs to bind to, and in that case it's useless (and perhaps even a source of trouble) to start more workers.
-
- Dec 08, 2020
-
-
Sushil Khanchi authored
-
- Dec 06, 2020
-
-
Georges Racinet authored
It wasn't needed in HDK context, because it was preinstalled from py-heptapod own test dependencies, but it's necessary to run the tests outside of HDK context (can be sometimes useful).
-
- Dec 04, 2020
-
-
Georges Racinet authored
This will have the `hg-current job` run in the base image that's now appropriate (`default` Docker tag instead of `latest`). The CI configuration doesn't have to differ between the two HGitaly branches (less prone to human errors during merges)
-
Georges Racinet authored
Hence in the HGitaly stable branch, we'll run in the `mercurial/hg-current:stable` base image, while in the HGitaly default branch, it'l be on `mercurial/hg-current:default`. (the base image is ready for that)
-
Georges Racinet authored
In the stable branch of HGitaly, we are using a fixed Mercurial version, therefore it's not interesting to check for incompatibilities with future versions: merges to default will tell us about them.
-
- Dec 03, 2020
-
-
Sushil Khanchi authored
As revs are computed using unfiltered repo, so later while converting them to GitCommit objects it should use unfiltered repo.
-
Georges Racinet authored
-
- Nov 26, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
HGitaly 0.5.0 features a simple prefork multiprocessing capability.
-
Georges Racinet authored
Mocking never looks as convincing, but in that case, it avoids assumptions on the surrounding networkin stack. For instance, our CI runs currently happens on Docker containers with no IPv6 capability, hence binding on `::1` just fails. Also, some build systems deliberately prohibit any networking in tests. This is (or has been) the case of Debian buildds.
-
- Nov 25, 2020
-
-
Georges Racinet authored
With the `hgitaly.workers` config knob it's possible to specify it. If not specified, the default value is the one computed in `hgitaly.server`, i.e. upper rounding of half the number of CPUs (as seen by Python `multiprocessing`).
-
Georges Racinet authored
See #2 This works for TCP sockets only and is essentially adapted from the standard multiprocessing example in the `grpc` package: pre-binding with `SO_REUSEPORT` and not starting the servers before forking. We're adding some logic to keep Unix Domain Socket mono-processed, because we can't support them in the same way (SO_REUSEPORT and associated kernel balancing is for IP sockets only). It looks like Unix Domain Socket support would be quite different, and probably would involve cooperation with upstream grpc code for server bind.
-
Georges Racinet authored
We're using as default the same port that is the default if no `--listen` option is passed.
-
Georges Racinet authored
This can already be used for some direct testing (e.g starting several clients to test server multiprocessing), and is generally meant as something the user will want to modify.
-
Sushil Khanchi authored
-
Georges Racinet authored
-
- Nov 22, 2020
-
-
Sushil Khanchi authored
-
- Nov 20, 2020
-
-
Sushil Khanchi authored
-
- Nov 22, 2020
-
-
Sushil Khanchi authored
-
- Nov 20, 2020
-
-
Georges Racinet authored
-
- Nov 19, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
Just to avoid any surprises, and besides it's more consistent to have the new versioning scheme for both.
-
Georges Racinet authored
NOT_FOUND is actually used in case the repository is not found only. Most calls will return their default value (0, empty string or `False`) if a lookup fails. Validated by corresponding RSpec tests and/or Golang reference code comparison.
-
Georges Racinet authored
If we have one failed lookup (for instance, ambiguous prefix), we must just ignore the given oid. We keep the simple and fast revset that will take care of the most common case of passed oids being actually prefixes that are long enough. Also behaviour if all lookups fail is to return an empty list, not to return NOT_FOUND error (means repo not found)
-
Georges Racinet authored
This was actually written in a comment right after the change, and validated by RSpec tests.
-
Georges Racinet authored
For instance, the main client (Rails app) remaps it to Gitlab::Git::Repository::NoRepository
-
- Nov 17, 2020
-
-
Georges Racinet authored
Same thing that our current hg-git conversion does, *but* this is known to have performance issues on large repositories. Putting this on a call path that the client has every right to think is cheap is very problematic. I would prefer a simple rule that Heptapod never exposes any obsolete head in its branch queries. The rationale for that would be that by definition Git does not either present any unreachable commit. For the time being (Heptapod 0.17), the projects backed by HGitaly are highly experimental, so we can probably live with it.
-
- Nov 18, 2020
-
-
Georges Racinet authored
As the comment explains, this is for now the only way to let the Rails app actually know that the default branch hasn't been set yet. After a lot of defaultings in the applicative code, this eventually activates the code that's responsible for actually setting it while receiving the first push. We can do something much more robust and maintainable, but that will be after the first push. Meanwhile, we do have functional tests about that to cover our backs.
-
Georges Racinet authored
We introduce a flag in the inner function that sorts out what to do of the branchmap entries, and use it for the default GitLab branch only. As the test demonstrates, the default GitLab branch will still point to the latest bookmarked head, which is consistent with what happens with "wild" multiple heads. This is a minor change of behaviour compared to the Heptapod standard, in which the default GitLab branch would not move in that case. The reason is that we don't have a natural support to store the previous position of the default GitLab branch. Of course hg-git based repositories have/had this extra state, in the form of the actual Git branch. The new behaviour is not worse and as much arbitrary as the previous one, and will of course be matched by py-heptapod's mirrorring to Git.
-
- Nov 17, 2020
-
-
Georges Racinet authored
In many cases, the client will send revision specification also in ref form, e.g, `refs/heads/branch/default`. We were already resolving branch names and tags, now we have to support this, too. We should do something similar about tags
-
Georges Racinet authored
The Rails app will store some changeset IDs and get back to HGitaly for information after a while. For instance, this is what happens with Merge Requests. It's perfectly possible that the changeset has become obsolete in the mean time. Hence the right thing to do is to make these commit methods work on the unfiltered repository. In order to mutualize, we're actually making the `gitlab_revision_changeset` return also obsolete changesets if queried by exact hash. This is consistent with the Git case: a ref should never be obsolete, but an exact lookup can return unreferenced commits. In the tests, it was about time for the `make_empty_repo` helper to activate the evolve extension. Thankfully no other test is affected (without evolve, `amend` would strip the previous changeset)
-