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 have context.project
  • worktree_paths returns nil
  • 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.

Edited by Furkan Ayhan

Merge request reports

Loading