- 14 Dec, 2020 1 commit
-
-
Sushil Khanchi authored
--HG-- branch : heptapod-stable
-
- 22 Aug, 2020 1 commit
-
-
Georges Racinet authored
This parallels what has been done upstream in `GitHttpController`, and wasn't called due to lack of the corresponding `before_action` (also removed upstream in `GitHttpController` but never present in the Mercurial variant). --HG-- branch : heptapod-stable
-
- 12 Jan, 2021 1 commit
-
-
Georges Racinet authored
These are the one modified while developping the token scope side of Mercurial pull mirrors, and will now be run by regular development pipelines. --HG-- branch : heptapod-stable
-
- 06 Jan, 2021 1 commit
-
-
Raphaël Gomès authored
This new scope allows for projects and maintainers to create tokens that are only valid for triggering existing resources. For now, this can only be used to trigger Mercurial pull mirrors, but other use-cases (like triggering pipelines, etc.) could be added in the future. --HG-- branch : heptapod-stable
-
- 10 Jan, 2021 2 commits
-
-
Georges Racinet authored
--HG-- branch : heptapod-stable
-
Georges Racinet authored
--HG-- branch : heptapod-stable
-
- 11 Jan, 2021 1 commit
-
-
Georges Racinet authored
--HG-- branch : heptapod-stable
-
- 06 Jan, 2021 2 commits
-
-
Georges Racinet authored
It made sense while the sharding and the extended scope were being developped. Now that they drove the 0.18 release, we can get back to normal enforcement. --HG-- branch : heptapod
-
Georges Racinet authored
It turns out that commit branch information is not available for "detached" Merge Request pipelines (neither Git nor Mercurial, although Mercurial would probably be a bit more relevant). It makes sense to use the target branch instead. --HG-- branch : heptapod
-
- 20 Dec, 2020 4 commits
-
-
Georges Racinet authored
Now it reflects the fact that pulling only protected branches is supported. --HG-- branch : heptapod
-
Georges Racinet authored
This introduces the `hg_id` and `short_hg_id` fields in the JSON response. The difference with `hpd_display_id` and `hpd_short_display_id` (used in the Web UI) is that they are exposed for Mercurial repositories only. For Mercurial native projects, these are identical to `id` and `short_id`. Closes #387 --HG-- branch : heptapod
-
Georges Racinet authored
Similarly to `hgsha`, and by contrast with `hpd_short_display_id`, this is `nil` if the repository isn't Mercurial. --HG-- branch : heptapod
-
Georges Racinet authored
For a while now, repositories have not necessarily been tied to Projects, but to more general "containers". This happens, e.g., with Snippets, Group Wikis. Besides, even on Mercurial Projects, Snippets repositories are Git. It is safer to let the Repository model handle that gracefully. --HG-- branch : heptapod
-
- 16 Dec, 2020 2 commits
-
-
Raphaël Gomès authored
--HG-- branch : heptapod
-
Raphaël Gomès authored
--HG-- branch : heptapod
-
- 15 Dec, 2020 3 commits
-
-
Georges Racinet authored
Probably not comprehensive enough, but writing new ones will be easy from now --HG-- branch : heptapod-stable
-
Georges Racinet authored
Heptapod 0.17 introduced the VCS-agnostic commit "display id", but was overly optimistic it could replace the commit ids in the JSON that is returned for client-side graph rendering. Indeed that JSON uses the plain ids to represent relationships. The right thing to do here is to get back to the anterior way of doing, just using the neutral method that will work for all types of repositories. Closes #385 --HG-- branch : heptapod-stable
-
Georges Racinet authored
This was missing, and could turn out to be useful, even though analysis shows that's not the case for #385. The new tests look to be trivial, because display ids are just the ids for commits of Git repositories. But the point is to check the APIs are internally consistent and avoid mistakes in refactorings. There is a test in HgGitRepository that makes sure that the Mercurial conversion for display is correct. --HG-- branch : heptapod-stable
-
- 09 Dec, 2020 1 commit
-
-
Raphaël Gomès authored
--HG-- branch : heptapod
-
- 16 Dec, 2020 1 commit
-
-
Georges Racinet authored
We get back what was done for 0.17.3 for the future 0.18.0 --HG-- branch : heptapod
-
- 14 Dec, 2020 9 commits
-
-
Georges Racinet authored
Certainly a leftover of the 13.5 merge, wasn't catched by functional tests until now. --HG-- branch : heptapod
-
Georges Racinet authored
Notably for typo in CI setup build script --HG-- branch : heptapod
-
Georges Racinet authored
--HG-- branch : heptapod
-
Georges Racinet authored
As the name suggests, it must create the repo. Also `for_write` is really useful, prevents potentially harmful hooks to be fired, notably. --HG-- branch : heptapod
-
Georges Racinet authored
hg_call is now used in the methods supporting backup and restoration (`#bundle_to_disk` and `#create_from_bundle`). There's no obvious GitLab user for these callers, and it should be irrelevant for Mercurial anyway. --HG-- branch : heptapod
-
Georges Racinet authored
The general move to the container concept broke this as well, but that is largely compensated by the abstractions in the base class that make the acess_wiki classes now simpler. --HG-- branch : heptapod
-
Georges Racinet authored
(the set method relies on the get method for comparisons). So, that was a piece of Python in Ruby. Obviously not covered either, except by functional tests. --HG-- branch : heptapod
-
Georges Racinet authored
Was previously in a presenter, moved to project, but obviously not covered yet by RSpec tests. --HG-- branch : heptapod
-
Georges Racinet authored
Now that manual jobs don't interest us so much, it's time to do it: GitLab never intended push pipelines and MR pipelines to go along very well. --HG-- branch : heptapod
-
- 09 Dec, 2020 1 commit
-
-
Georges Racinet authored
From now on, we'll be using two pip requirement files. The options to disable Rust in Heptapod Rails and Heptapod Shell are not yet available at this point (see #386) --HG-- branch : heptapod
-
- 14 Dec, 2020 2 commits
-
-
Georges Racinet authored
Allows to disable the Rust Python extensions in calls performed from the Rails application Closes #386 --HG-- branch : heptapod
-
Georges Racinet authored
--HG-- branch : heptapod
-
- 13 Dec, 2020 1 commit
-
-
Georges Racinet authored
Wanted to do this a long time ago, much more comfortable with this now that we have extensive tests. Will be needed to add `HGMODULEPOLICY` to the game --HG-- branch : heptapod
-
- 11 Dec, 2020 1 commit
-
-
Georges Racinet authored
The requirements file was split in two, and Mercurial version will have to be maintained both in `hg.req` and `hg-rust.req`. The new `requirements-rust.txt` has pip install with the Rust Python extensions. Using it without a working Rust toolchain is a hard install failure. The existing `requirements.txt` will work exactly as before. --HG-- branch : heptapod
-
- 08 Dec, 2020 6 commits
-
-
Georges Racinet authored
Typical of code that's been manually tested only so far. --HG-- branch : heptapod-stable
-
Georges Racinet authored
The most notable thing is that pip outputs most of its message to stderr, which wreaked the ordering with out prints. --HG-- branch : heptapod-stable
-
Georges Racinet authored
It was useful to have this when we were just getting started with RSpec tests and the CI, but nowadays this is mostly a source of double pipelines. Keeping the manual option, though. --HG-- branch : heptapod-stable
-
Georges Racinet authored
It could be inconsistent with INTERPRETER. This is precisely what `$INTERPRETER -m pip` is supposed to solve. --HG-- branch : heptapod-stable
-
Georges Racinet authored
Thought of the decoding several times but still had forgotten it in the previously published version. --HG-- branch : heptapod-stable
-
Georges Racinet authored
Regrouping constants for executables. Also nicer for trying the script with a local modification. --HG-- branch : heptapod-stable
-