Actual behavior
For a given workflow run:
The requested event creates the CI server / pipeline successfully.
The in_progress and completed events do not consistently resolve that same pipeline.
Instead, they appear to resolve a different pipeline identity, often with /main involved.
This makes the lifecycle inconsistent for the same run:
pipeline created under one identity
later run status / test result updates target another identity
Observed behavior is roughly:
requested: pipeline created as something like repo-level pipeline
in_progress / completed: action looks for a branch-qualified variant, often ending with /main
Expected behavior
All workflow_run event types for the same GitHub workflow run should resolve to the exact same CI server and pipeline identity.
If requested creates the pipeline, then in_progress and completed should update that same pipeline rather than resolving a different one.
Why this looks like an action issue
This seems to be internal pipeline identity inconsistency across event handling, because:
the same integration workflow handles all three event types
the same pipelineNamePattern is configured
the same GitHub workflow run is being reflected
yet the resolved pipeline identity appears to differ between requested and later events
Impact
This causes:
inconsistent pipeline topology in Octane / ValueEdge
missing or misrouted run state transitions
unreliable automated test run reflection across the workflow lifecycle
Request
Please verify whether pipeline identification is computed differently for:
workflow_run.requested
workflow_run.in_progress
workflow_run.completed
especially around:
branch handling
default branch suffixing such as /main
pipeline key generation / lookup
multi-branch pipeline resolution
Additional notes
We also noticed that the action currently hard-codes converted test fields like:
Test_Level = Unit Test
Test_Type = Sanity
That is a separate issue, but mentioning it here in case the same code paths are involved in event-specific handling.
If useful, I can also provide:
full debug logs for all three event types
workflow run IDs
screenshots of the pipelines created / resolved in Octane
Actual behavior
For a given workflow run:
The requested event creates the CI server / pipeline successfully.
The in_progress and completed events do not consistently resolve that same pipeline.
Instead, they appear to resolve a different pipeline identity, often with /main involved.
This makes the lifecycle inconsistent for the same run:
pipeline created under one identity
later run status / test result updates target another identity
Observed behavior is roughly:
requested: pipeline created as something like repo-level pipeline
in_progress / completed: action looks for a branch-qualified variant, often ending with /main
Expected behavior
All workflow_run event types for the same GitHub workflow run should resolve to the exact same CI server and pipeline identity.
If requested creates the pipeline, then in_progress and completed should update that same pipeline rather than resolving a different one.
Why this looks like an action issue
This seems to be internal pipeline identity inconsistency across event handling, because:
the same integration workflow handles all three event types
the same pipelineNamePattern is configured
the same GitHub workflow run is being reflected
yet the resolved pipeline identity appears to differ between requested and later events
Impact
This causes:
inconsistent pipeline topology in Octane / ValueEdge
missing or misrouted run state transitions
unreliable automated test run reflection across the workflow lifecycle
Request
Please verify whether pipeline identification is computed differently for:
workflow_run.requested
workflow_run.in_progress
workflow_run.completed
especially around:
branch handling
default branch suffixing such as /main
pipeline key generation / lookup
multi-branch pipeline resolution
Additional notes
We also noticed that the action currently hard-codes converted test fields like:
Test_Level = Unit Test
Test_Type = Sanity
That is a separate issue, but mentioning it here in case the same code paths are involved in event-specific handling.
If useful, I can also provide:
full debug logs for all three event types
workflow run IDs
screenshots of the pipelines created / resolved in Octane