Fix missing project for included remote file including with rules:exists
What does this MR do and why?
This MR resolves the bug when an included remote file has an include with rules:exists. A bug occurs because the remote context does not have a project.
Note: This MR does not change behavior. Normally, for include:rules in remote included files, we ignore other rules (if), but raise an error in exists. So, with this MR, we start ignoring exists.
Related to #365382 (closed)
More explanation;
If the remote file has rules inside of their includes, we cannot process them because we don't have enough context to know file changes, variables, etc.
Currently, when you define;
# http://example.com/random-address/include.yml
include:
- remote: http://example.com/random-address/builds.yml
rules:
- if: $CI_COMMIT_BRANCH == "master"
the rule is always evaluated as false and the file will not be included.
However, when you define the rule with exists;
# http://example.com/random-address/include.yml
include:
- remote: http://example.com/random-address/builds.yml
rules:
- exists: [Dockerfile]
we get an error.
We have this error because in lib/gitlab/ci/build/rules/rule/clause/exists.rb;
def satisfied_by?(_pipeline, context)
paths = worktree_paths(context)
exact_matches?(paths) || pattern_matches?(paths)
end
private
def worktree_paths(context)
return unless context.project
if @top_level_only
context.top_level_worktree_paths
else
context.all_worktree_paths
end
end
def exact_matches?(paths)
@exact_globs.any? { |glob| paths.bsearch { |path| glob <=> path } }
end
- we don't have
context, so we don't havecontext.project -
worktree_pathsreturnsnil - and we try to call methods on
paths, which is nil.
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.