CI: Trigger gems' child pipelines when Gemfile.lock changes
What does this MR do and why?
Because vendored gems can depend on each other we need to refresh its
Gemfile.lock
whenever the monorepo Gemfile.lock
has changed.
Checking gems/*/Gemfile.lock
is unnecessary because each change of an
runtime dependency is also reflected in monorepo's Gemfile.lock
.
Closes #417428 (closed).
How to validate on CI
- Update
gems/gitlab-rspec/gitlab-rspec.gemspec
and runbundle
ingems/gitlab-rspec
and monorepo's root - Commit and push:
diff --git a/Gemfile.lock b/Gemfile.lock
index 4597ca23eb76..cca810b815e9 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -38,7 +38,7 @@ PATH
specs:
gitlab-rspec (0.1.0)
activesupport (>= 6.1, < 8)
- rspec (~> 3.0)
+ rspec (~> 3.1)
PATH
remote: gems/gitlab-safe_request_store
diff --git a/gems/gitlab-rspec/Gemfile.lock b/gems/gitlab-rspec/Gemfile.lock
index 7d07ad441acd..88d11da21f0e 100644
--- a/gems/gitlab-rspec/Gemfile.lock
+++ b/gems/gitlab-rspec/Gemfile.lock
@@ -3,7 +3,7 @@ PATH
specs:
gitlab-rspec (0.1.0)
activesupport (>= 6.1, < 8)
- rspec (~> 3.0)
+ rspec (~> 3.1)
GEM
remote: https://rubygems.org/
diff --git a/gems/gitlab-rspec/gitlab-rspec.gemspec b/gems/gitlab-rspec/gitlab-rspec.gemspec
index 8e41e5436e68..15bb316ab079 100644
--- a/gems/gitlab-rspec/gitlab-rspec.gemspec
+++ b/gems/gitlab-rspec/gitlab-rspec.gemspec
@@ -19,7 +19,7 @@ Gem::Specification.new do |spec|
spec.require_paths = ["lib"]
spec.add_runtime_dependency "activesupport", ">= 6.1", "< 8"
- spec.add_runtime_dependency "rspec", "~> 3.0"
+ spec.add_runtime_dependency "rspec", "~> 3.1"
spec.add_development_dependency "factory_bot_rails", "~> 6.2.0"
spec.add_development_dependency "gitlab-styles", "~> 10.1.0"
- See CI triggering all child pipelines for
gems/
and see them🔴 fail - https://gitlab.com/gitlab-org/gitlab/-/pipelines/1045887437 (test MR)- This replicates !134777 (merged)
https://gitlab.com/gitlab-org/gitlab/-/pipelines/1045880657 |
---|
![]() |
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by Peter Leitzen