- 23 Dec, 2020 1 commit
-
-
Ben Avison authored
Resolves bug introduced in commit 9c61e2f0.
-
- 11 Dec, 2020 2 commits
-
-
Ben Avison authored
If the following happens: * a GitLab runner recursively clones a superproject * one or more submodules has changes upstream and the submodule references in the superproject have been updated to point to it * a new pipeline is launched for the new superproject revision then, while the runner would fetch changes to the superproject, it wasn't doing so for the submodules. Ironically, we do both `git submodule update` and `git submodule update --remote` in different pipeline stages and the latter includes an implicit submodule fetch - but that was the later stage which we don't get as far as. To fix this, while retaining the pipeline stage order, include an explicit fetch in the earlier stage (and remove the implicit fetch in the later one, since that now merely wastes time).
-
Ben Avison authored
This one is a special case where the superproject name mismatches the corresponding Env (and thus Components) file. Our own CI script also didn't previously support the *removal* of an autogenerated YAML file. This should be a rare occurrence, but it's best to automate this also. Also support force-pushing to the submodule; this will be required in most cases where the pipeline was triggered by a force-push to *this* project.
-
- 25 Nov, 2020 1 commit
-
-
Ben Avison authored
-