- 08 Dec, 2020 1 commit
-
-
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 1 commit
-
-
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
-
- 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
-
- 07 Dec, 2020 8 commits
-
-
Georges Racinet authored
Closes #382 --HG-- branch : heptapod-stable
-
Georges Racinet authored
if it works, we'll probably just keep the result and enable the job only on GitLab version bumps (perhaps with the `changes` directive) --HG-- branch : heptapod-stable
-
Georges Racinet authored
Heads up: in release branches, the tests are expected to pass for the versions specified in `python/requirements.txt`. Was spotted while working on the Gitaly prebuild, but really has to be fixed: we were running the tests always against the default branch of the Python dependencies (HGitaly and py-heptapod). There is a complication with tags, and especially release branches. For the latter, there is no simple way to know which is the appropriate branch of the Python deps. Shortly after the beginning of the release branch, it would clearly be `default`, but after the swap of branches in the Rails app, it would be `stable`. For tags, the tests are run against the exact versions specified in `python/requirements.txt`, that was easy. For release branches, we just do the same. This is a lesser evil. Hence now, pushes to release branches are expected to make the appropriate version bumps (this was already quite often the case). --HG-- branch : heptapod-stable
-
Georges Racinet authored
Now there's a separate function to update configuration files, will be useful for next change. --HG-- branch : heptapod-stable
-
Georges Racinet authored
This creates and preserves the `tmp/tests/hgitaly` subdir and separates for CI the install (build) and startup (spawn) phases. By putting `hgitaly.socket` in that preserved directory, it also fixes test runs on developer machines involving several spec files (previously, the socket was destroyed at the end of each spec file) This is heavier than strictly needed for HGitaly, but matching what is already done for Gitaly will help us schedule differently (prepare phase, straight download), and prebuilding just Gitaly, but with `TestEnv` that actually starts HGitaly is an unmaintanable mess. --HG-- branch : heptapod-stable
-
Georges Racinet authored
The only conclusion is that it worked because almost all the runners already had them (spotted on a case where concurrent-1 got used) --HG-- branch : heptapod-stable
-
Georges Racinet authored
--HG-- branch : heptapod-stable
-
Georges Racinet authored
about time. --HG-- branch : heptapod-stable
-
- 02 Dec, 2020 2 commits
-
-
Georges Racinet authored
In practice, the feature will work for the "Pipeline Emails" integration, because these are triggered separately from regular pipeline emails, with exactly the list as given in the integration config. Turns out that in all RSpec tests/examples about pipeline emails, the list of recipients was actually `nil`, because that is the email of the testing user. The case hence seems articial, but let's not break because of that. In the new test we don't use the `deliver_to` from `EmailSpec` because it apparently actually reconstructs the envelop-to from To and Bcc values. Finally, the test in spec/models was explicitely looking for recipients in the Bcc field, it had to be adapted after CI complained. --HG-- branch : heptapod
-
Raphaël Gomès authored
--HG-- branch : heptapod
-
- 27 Nov, 2020 1 commit
-
-
Georges Racinet authored
This will make cleaning up much easier and safer --HG-- branch : heptapod
-
- 10 Nov, 2020 2 commits
-
-
Georges Racinet authored
The Octobus mirror is nice, but it can be up to 10mn behind the main repo. Moreover, these are small repos and nowadays foss.heptapod.net is as much efficient as mirror.o.n --HG-- branch : heptapod
-
Georges Racinet authored
The intent has always been to be on the (assumed single) head of default. But without evolve/topic, it was actually the latest draft. --HG-- branch : heptapod
-
- 07 Nov, 2020 2 commits
-
-
Georges Racinet authored
In the helper, we're now making the distinction between all possible values and those that are enabled in the application settings. In the default value, we're in particular treating the corner case where the library-level default is not allowed by Application Settings. It is not expected with the current possible values to happen often, but one may even imagine people restricting to Git as part as a transition plan from upstream GitLab CE to Heptapod. We don't want to do the same for the API, because the default is quite arbitrary in that case, and it's not guaranteed a human being would be witnessing its value. --HG-- branch : heptapod
-
Georges Racinet authored
This allows to fill in the new `vcs_types` field. --HG-- branch : heptapod
-
- 26 Oct, 2020 2 commits
-
-
Georges Racinet authored
--HG-- branch : heptapod-stable
-
Arguably, this is masking the real issue, which is #360, but we the benefits of having these tests in CI outweigh the drawback of not fixing the issue. Also, it's arguably a good thing to validate that the README init option works in Heptapod for Git projects. --HG-- branch : heptapod-stable
-
- 13 Oct, 2020 1 commit
-
-
Georges Racinet authored
While investigating some failed builds, I found that the HGitaly repo couldn't be updated for them (failed pull) and that upgrading hg-evolve fixed that, as well as the whole build. --HG-- branch : heptapod
-
- 19 Sep, 2020 1 commit
-
-
GitLab Bot authored
-
- 21 Sep, 2020 1 commit
-
-
Georges Racinet authored
Closes #345. The selective pull we're adding should be enough in most cases with our current branching strategy. Since we can't really test it without polluting the tags, and it's not a really big problem if it doesn't work, we're allowing the pull to fail. This can be made stricter in a follow-up. --HG-- branch : heptapod
-
- 26 Sep, 2020 1 commit
-
-
Georges Racinet authored
These will from now be launched by CI. The previously split methods made this easier, although we needed one more, to have a constant `Pathname` instance to mock. --HG-- branch : heptapod-stable
-
- 03 Sep, 2020 1 commit
-
-
Georges Racinet authored
The job is manual and non-blocking if from a regular push or from the Web UI. It is in a separate stage because it felt just wrong to label it as 'test'. For the time being, we're making it not depend on tests to pass, because that's too much of a pain while we are working on the packaging itself. We may want that in the future, though, for final validation before release. Closes: #339 --HG-- branch : heptapod
-
- 20 Aug, 2020 1 commit
-
-
GitLab Bot authored
-
- 27 Jul, 2020 2 commits
-
-
Georges Racinet authored
This can help with hgitaly installation. --HG-- branch : heptapod
-
Georges Racinet authored
We'll still need to run `hgitaly-serve` to write RSpec tests relying on HGitaly, but at this point we should have all dependencies to do so. --HG-- branch : heptapod
-
- 28 Jul, 2020 1 commit
-
-
Georges Racinet authored
Closes #316 This finishes the work started in the stable branch (not RSpec capable) by executing the new tests in Heptapod CI. --HG-- branch : heptapod
-
- 27 Jul, 2020 2 commits
-
-
Georges Racinet authored
--HG-- branch : heptapod
-
Georges Racinet authored
This is done by a separate Python script originally because it'd otherwise be an escaping nightmare with sed commands as `prepare_build.sh` issues (especially because we'd need an absolute path, and hence to escape $PWD). Now this script does the following: - create a virtualenv - install all py-heptapod needed dependencies, for now in a Python2 virtual environment. We'll have to provide a recent Python3 for HGitaly later. - configure GitLab for Mercurial operation. This is done after `TestEnv.init` because the later would cancel our changes in `config/gitlab.yml` Note also that putting the local `test.hgrc` file in `tmp/tests` would not work: something inside the `bin/rspec` run would delete it before the time when the actual tests need it. --HG-- branch : heptapod
-
- 20 Jul, 2020 1 commit
-
-
GitLab Bot authored
-
- 25 Jul, 2020 3 commits
-
-
Georges Racinet authored
This adds less than a minute on my workstation to the execution time. A previous attempt to add all CI related tests ended up with a failure on CI only (see #318) --HG-- branch : heptapod
-
Georges Racinet authored
Running these tests that have just been fixed make the full run take a bit less than 6.5 minutes on my workstation (from about 5). --HG-- branch : heptapod
-
Georges Racinet authored
and of course we want to run it in the CI. This runs in about 5 minutes on my workstation in HDK context (hence with almost every dependency already provided). We'll add new test patterns to this list as we make them pass. Later on we'll probably want to split it, maybe run several jobs etc. --HG-- branch : heptapod
-
- 18 Jun, 2020 1 commit
-
-
GitLab Bot authored
-
- 20 May, 2020 1 commit
-
-
GitLab Bot authored
-
- 09 Apr, 2020 1 commit
-
-
GitLab Bot authored
-
- 07 Apr, 2020 1 commit
-
-
GitLab Bot authored
-
- 01 Apr, 2020 1 commit
-
-
GitLab Bot authored
-