DEV Community

Query Filter
Query Filter

Posted on

docker-191

If your Harness pipeline is still triggering on other branches (or failing to run at all) after adding the when condition, the issue usually boils down to a conflict between Task-level vs. Pipeline-level scope, or how Harness registers its Webhook Triggers.

Let’s troubleshoot the exact reasons why it’s slipping through and how to lock it down.

1. The Scope Trap: You filtered the Task, not the Pipeline

In your original pipeline.yaml, you added the when block directly under the gradle-build task:

    - ref: java-gradle-build
      name: gradle-build
      when:
        branch: "release/*"
Enter fullscreen mode Exit fullscreen mode

Why it "isn't working": Placing a when condition inside an individual task array element tells Harness: "Go ahead and trigger the pipeline execution for **every* branch push, but when you reach this specific step, skip it if it’s not a release branch."* If you have other tasks in your pipeline (like checkout, linting, or notifications) that don't have this condition, the pipeline will still spin up, execute those steps, and appear as a "Successful" or "Partially Skipped" execution in your dashboard.

The Fix: Move the Condition to the Stage or Pipeline Level

To prevent the execution from starting altogether, you need to apply the filter at the root execution boundary. In Harness YAML, this is handled via a pipeline-level policy or a dedicated Trigger Matrix.

Check the very top of your pipeline.yaml or your separate trigger configuration file and restructure it to filter at the root:

pipeline:
  name: Comet Build Pipeline
  identifier: Comet_Build_Pipeline
  allowStageExecutions: true
  # Filter at the root stage boundary
  stages:
    - stage:
        name: Build Stage
        identifier: Build_Stage
        type: CI
        spec:
          execution:
            steps:
              # Your tasks go here...
        when:
          pipelineStatus: Success
          branch: "release/*"  # <-- Blocks the entire stage execution early
Enter fullscreen mode Exit fullscreen mode

2. Harness Webhook Trigger Overrides (UI Config)

If your pipeline configuration is completely correct in the YAML, but pushes to a feature branch like leonid_configServerJMXClient_java21 are still launching full executions, the Harness platform's UI Trigger rules are overriding your file logic.

In Harness, Git Webhook Triggers often evaluate branch constraints before they even open or parse your pipeline.yaml.

How to verify and fix this in the Harness UI:

  1. Open your project dashboard in Harness.
  2. Navigate to Pipelines and click on your specific migration pipeline.
  3. Click on the Triggers tab at the top right of the screen.
  4. Locate your active Git Webhook Trigger (e.g., "On Push") and click Edit.
  5. Scroll down to the Conditions or Attribute Filters section.
  6. Look at the Branch filter field. If it says Any or is left blank, Harness will start a pipeline execution for every single push across the entire repository, ignoring your local YAML intent.
  7. Change the matching type to Regex or Wildcard and explicitly input release/*.

3. Strict Syntax Validation for Harness Git Experience

Depending on the specific version of the Harness execution engine your team is hosting, string matching can be strict. Try these alternative variations if release/* is ignored:

  • Single Quotes: Ensure the YAML parser isn't evaluating the asterisk as a structural alias pointer: branch: 'release/*'
  • Explicit Array Matching: If your schema supports multi-branch arrays: 
when:
  branch:
    include: ["release/*"]
Enter fullscreen mode Exit fullscreen mode

Check your Harness execution logs for the failed run—does the execution history tree show the gradle-build step as a greyed-out "Skipped" icon, or is it trying to build the feature branch code anyway?

Top comments (0)