Skip to content

feat: add workflow rules to base configuration#20

Merged
konradmichalik merged 3 commits into
mainfrom
feature/workflow-rules
Apr 17, 2026
Merged

feat: add workflow rules to base configuration#20
konradmichalik merged 3 commits into
mainfrom
feature/workflow-rules

Conversation

@konradmichalik
Copy link
Copy Markdown
Contributor

@konradmichalik konradmichalik commented Apr 17, 2026

Summary

  • Add explicit workflow:rules block to .base.yaml to control when pipelines are created
  • Covers merge requests, schedules, downstream pipelines, web triggers, tags, and branch commits

Changes

  • .base.yaml — new workflow:rules section defining pipeline creation conditions

Summary by CodeRabbit

  • Chores
    • Updated CI/CD pipeline workflow rules to ensure automated builds and tests trigger reliably for merge requests, scheduled runs, direct triggers, web-triggered pipelines, tagged commits, and branch commits.

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Apr 17, 2026

Warning

Rate limit exceeded

@konradmichalik has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 26 minutes and 39 seconds before requesting another review.

Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 26 minutes and 39 seconds.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: eec971c1-10a6-42cb-b9c0-07b2ef42aaba

📥 Commits

Reviewing files that changed from the base of the PR and between 6888d0c and 3afd15a.

📒 Files selected for processing (2)
  • build/build-node.yaml
  • build/build-php.yaml
📝 Walkthrough

Walkthrough

Added a new workflow section to the CI configuration with conditional rules that govern when CI pipelines are triggered, allowing pipelines for merge requests, scheduled runs, pipeline triggers, web-triggered pipelines, tagged commits, and branch commits.

Changes

Cohort / File(s) Summary
CI Workflow Configuration
.base.yaml
Added top-level workflow section with rules to explicitly control pipeline creation based on source (merge request events, scheduled, pipeline, web) and commit context (tags, branches).

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐰 A workflow so bright, with rules crystal clear,
Pipelines shall run when conditions appear,
Merges and schedules, web triggers galore,
Tags and branches—the gates to explore!
The CI now knows when to dance and when wait,
Configuration refined, our builds are first-rate! 🚀

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately summarizes the main change: adding workflow rules to the base CI configuration file.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feature/workflow-rules

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.base.yaml:
- Around line 11-16: The branch pipeline is being created alongside the
merge_request_event pipeline causing duplicates; update the rules so the
CI_COMMIT_BRANCH branch rule is guarded by a check on $CI_OPEN_MERGE_REQUESTS
(i.e., only run the branch pipeline when there are no open merge requests for
that branch). Concretely, add a precondition before the CI_COMMIT_BRANCH rule
that checks $CI_OPEN_MERGE_REQUESTS is empty/absent, keep the existing
merge_request_event rule unchanged, and ensure the rule order places this guard
before the branch rule so pushes with open MRs skip the branch pipeline.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 6b645919-b698-42eb-a39c-6f6c69d89b89

📥 Commits

Reviewing files that changed from the base of the PR and between 500ef8d and 6888d0c.

📒 Files selected for processing (1)
  • .base.yaml

Comment thread .base.yaml Outdated
Comment on lines +11 to +16
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_PIPELINE_SOURCE == "schedule"
- if: $CI_PIPELINE_SOURCE == "pipeline"
- if: $CI_PIPELINE_SOURCE == "web"
- if: $CI_COMMIT_TAG
- if: $CI_COMMIT_BRANCH
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

find . -name ".base.yaml" -o -name "base.yaml" | head -20

Repository: move-elevator/gitlab-ci-templates

Length of output: 89


🏁 Script executed:

cat -n ./.base.yaml

Repository: move-elevator/gitlab-ci-templates

Length of output: 5366


🏁 Script executed:

# Check if there are more files or if jobs are defined elsewhere
wc -l ./.base.yaml

Repository: move-elevator/gitlab-ci-templates

Length of output: 93


🏁 Script executed:

tail -n 109 ./.base.yaml | head -60

Repository: move-elevator/gitlab-ci-templates

Length of output: 2525


🏁 Script executed:

# Check if there are any job definitions in the file with when: never clauses
grep -n "when:" ./.base.yaml

Repository: move-elevator/gitlab-ci-templates

Length of output: 59


🏁 Script executed:

# Look for any job definitions in .base.yaml (they start with a name followed by colon, not indented like config items)
grep -nE "^[a-zA-Z0-9_.-]+:" ./.base.yaml | head -20

Repository: move-elevator/gitlab-ci-templates

Length of output: 212


🏁 Script executed:

# Search for other files that might use .base.yaml as include
find . -name "*.yaml" -o -name "*.yml" | head -20

Repository: move-elevator/gitlab-ci-templates

Length of output: 724


🏁 Script executed:

# Check one of the analyze files to see how jobs are structured and if they reference .base.yaml
head -50 ./analyze/analyze-php-cs-fixer.yaml

Repository: move-elevator/gitlab-ci-templates

Length of output: 703


🏁 Script executed:

# Check if this pattern is consistent - look for job rules in other files
grep -A 10 "rules:" ./analyze/*.yaml | grep -E "(rules:|when:|merge_request_event)" | head -40

Repository: move-elevator/gitlab-ci-templates

Length of output: 3400


🏁 Script executed:

# Check build jobs as well to see if the pattern is consistent
grep -A 10 "rules:" ./build/*.yaml | grep -E "(rules:|when:|merge_request_event)" | head -40

Repository: move-elevator/gitlab-ci-templates

Length of output: 777


🏁 Script executed:

# Check the deploy files to see if they have different job rules
cat ./deploy/deploy-feature-cleanup-downstream.yaml

Repository: move-elevator/gitlab-ci-templates

Length of output: 561


🏁 Script executed:

# Let's check a deploy job to see a simpler rule set
cat ./deploy/deploy-stage.yaml 2>/dev/null || cat ./deploy/deploy-*.yaml | head -60

Repository: move-elevator/gitlab-ci-templates

Length of output: 668


🏁 Script executed:

# Let's check the git history to understand the context of this change
git log --oneline -20 2>/dev/null || echo "Git history not available"

Repository: move-elevator/gitlab-ci-templates

Length of output: 131


🌐 Web query:

GitLab CI $CI_OPEN_MERGE_REQUESTS variable workflow rules

💡 Result:

The $CI_OPEN_MERGE_REQUESTS predefined variable in GitLab CI/CD is a comma-separated list of up to four open merge request IIDs (e.g., "gitlab-org/gitlab!333,gitlab-org/gitlab-foss!11") for the current branch and project as the source. It is available in pre-pipeline phase for branch pipelines and merge request pipelines when the branch has associated open merge requests (introduced in GitLab 13.8). It is commonly used in workflow:rules to prevent duplicate pipelines when both branch and merge request pipelines would trigger on a push to a branch with open MRs. Example configuration: workflow: rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event" - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS when: never - if: $CI_COMMIT_BRANCH This runs: - Merge request pipelines for merge_request_event. - Skips branch pipelines (push) if open MRs exist for the branch. - Runs branch pipelines only if no open MRs. The variable is set only if open MRs exist; otherwise, it is unset (if: $CI_OPEN_MERGE_REQUESTS evaluates false).

Citations:


🏁 Script executed:

# Check if there are any jobs that actually allow merge_request_event, schedule, or pipeline sources
# by looking for jobs that either don't have rules or have different rules
find . -name "*.yaml" -o -name "*.yml" | xargs grep -L "when: never" | xargs grep -l "merge_request_event\|CI_PIPELINE_SOURCE" 2>/dev/null | head -10

Repository: move-elevator/gitlab-ci-templates

Length of output: 89


Duplicate pipelines will be created for branches with open merge requests.

When you push to a branch with an open MR, the current workflow rules (lines 11 and 16) trigger two separate pipelines: one for merge_request_event and one for CI_COMMIT_BRANCH. The first pipeline runs with no jobs since all jobs explicitly block merge_request_event source with when: never, creating an empty/wasted pipeline.

To prevent this, add a guard before the branch rule using $CI_OPEN_MERGE_REQUESTS:

🔧 Proposed fix
 workflow:
   rules:
     - if: $CI_PIPELINE_SOURCE == "merge_request_event"
     - if: $CI_PIPELINE_SOURCE == "schedule"
     - if: $CI_PIPELINE_SOURCE == "pipeline"
     - if: $CI_PIPELINE_SOURCE == "web"
     - if: $CI_COMMIT_TAG
+    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
+      when: never
     - if: $CI_COMMIT_BRANCH

This skips the branch pipeline when an MR is already open for that branch, eliminating the duplicate pipeline.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_PIPELINE_SOURCE == "schedule"
- if: $CI_PIPELINE_SOURCE == "pipeline"
- if: $CI_PIPELINE_SOURCE == "web"
- if: $CI_COMMIT_TAG
- if: $CI_COMMIT_BRANCH
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_PIPELINE_SOURCE == "schedule"
- if: $CI_PIPELINE_SOURCE == "pipeline"
- if: $CI_PIPELINE_SOURCE == "web"
- if: $CI_COMMIT_TAG
- if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
when: never
- if: $CI_COMMIT_BRANCH
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.base.yaml around lines 11 - 16, The branch pipeline is being created
alongside the merge_request_event pipeline causing duplicates; update the rules
so the CI_COMMIT_BRANCH branch rule is guarded by a check on
$CI_OPEN_MERGE_REQUESTS (i.e., only run the branch pipeline when there are no
open merge requests for that branch). Concretely, add a precondition before the
CI_COMMIT_BRANCH rule that checks $CI_OPEN_MERGE_REQUESTS is empty/absent, keep
the existing merge_request_event rule unchanged, and ensure the rule order
places this guard before the branch rule so pushes with open MRs skip the branch
pipeline.

@konradmichalik konradmichalik merged commit f4b4543 into main Apr 17, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants