- 16 Dec, 2020 1 commit
-
-
Raphaël Gomès authored
--HG-- branch : heptapod
-
- 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
-
- 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
-
- 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 13 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
-
Georges Racinet authored
It's been at last added to the dependencies of py-heptapod. --HG-- branch : heptapod-stable
-
Georges Racinet authored
It is fresh enough in the base image to avoid problems such as topic awareness with hg-evolve < 9.3.0. The requirements of py-heptapod and HGitaly should do the rest. --HG-- branch : heptapod-stable
-
Georges Racinet authored
It should be a bit faster, and pip 20.3 will perform a better analysis of dependencies with a single call. --HG-- branch : heptapod-stable
-
Georges Racinet authored
The base image now provides pip 20.3, which is the pivotal version for the new dependency conflict assessment. --HG-- branch : heptapod-stable
-
Georges Racinet authored
--HG-- branch : heptapod-stable
-
Georges Racinet authored
Was leftover as local mod in one of the latest amends for !137 --HG-- branch : heptapod-stable
-
Georges Racinet authored
This *should* make it work for pipelines of tags and release branches, that will install directly from PyPI. Also, the spawn script adopts the call of `hg hpd-versions`, avoiding hardcoded paths which were incorrect (but most of our runners still have old directories laying around, so this went under the radar). The same holds with the content of `required.hgrc`. --HG-- branch : heptapod-stable
-
- 06 Dec, 2020 3 commits
-
-
Georges Racinet authored
Starting with 6 jobs should give us pipelines around 15 minutes, but perhaps we'll need to cache download.heptapod.net Worth of notice is that for the `parallel` directive, GitLab chose the exact environment variables expected by knapsack. Lately we've needed a tremendous amount of retries on one example (#384), that explains the very high `RETRIES` setting. --HG-- branch : heptapod-stable
-
Georges Racinet authored
These were copied over from other tests and are of no use in that one (`Term` is about end-user terms acceptance, just to underline how far that is from the concerns of this test). --HG-- branch : heptapod-stable
-
Georges Racinet authored
Killing the main process had no other impact on the worker processes than to orphan them. Depends on hgitaly#34 for the wished result. --HG-- branch : heptapod-stable
-
- 08 Dec, 2020 1 commit
-
-
Georges Racinet authored
Knapsack is the sharding tool also used by upstream GitLab. To balance the shards, it uses a time table (the report file). Our main difference with upstream is that we have a checked in report file instead of maintaining it from the CI in a S3 bucket. Updates will have to be done manually. There is a companion `heptapod-rspec-parallel` script in the HDK (for lack of a better place) that can leverage knapsack to run the tests across several entire HDK workspaces. --HG-- branch : heptapod-stable
-
- 05 Dec, 2020 3 commits
-
-
Georges Racinet authored
First experiences for parallelization of RSpec tests will be done on personal workstations. The KNAPSACK_GENERATE_REPORT variable should be enough to gate it. --HG-- branch : heptapod-stable
-
Georges Racinet authored
It turns out that these tests don't need the branches to actually exist. This gets the time to run this RSpec file down from 10 minutes to less than 4 on my development workstation. That is enough to make sharding meaningful. Of course that raises the question whether they test anything, since some expected Forbidden could actually now be raised for the wrong reason. There is the case of the `safe_commit_for_new_protected_branch?` where one checks that protected branch rules are applied even if the commit actually creates the protected branch (through wildcard protection, that is indeed possible), but this is not currently covered, although it should. In other words actual coverage is no worse, and we should add new tests for the cases that aren't strongly covered, (perhaps UPSTREAM). The empty repo is a special case, but the general factory fixture takes care of that. --HG-- branch : heptapod-stable
-
Georges Racinet authored
Thanks to this, the running time goes down from about 3mn to 1mn and 50s on my system. The LFS tests are probably irrelevant: the day we activate Mercurial's version of LFS, we will certainly have to perform other types of checks. But then, they will perhaps serve as reminders that there is something to adapt. --HG-- branch : heptapod-stable
-