feat(ci): advanced triggers for integration-tests#21686
feat(ci): advanced triggers for integration-tests#21686
Conversation
|
✅ No conflicts with other open PRs targeting |
erikburt
force-pushed
the
feat/integration-tests-advanced-triggers
branch
from
3d3331c to
a8498da
Compare
product-security-plaid-production
bot
requested review from
gustavogama-cll and
kalverra
There was a problem hiding this comment.
Pull request overview
Risk Rating: HIGH — CI trigger logic changes can unintentionally suppress required integration test runs (or cause unexpected runs), impacting release confidence.
This PR updates the Integration Tests workflow to use the org-standard advanced-triggers action instead of dorny/paths-filter, aiming to reduce unnecessary workflow executions via more granular file-set based triggers.
Changes:
- Replaced
dorny/paths-filterwithsmartcontractkit/.github/actions/advanced-triggersinintegration-tests.yml. - Introduced
file-setsandtriggersdefinitions forcre-e2e,core-e2e, andccip-e2e. - Updated downstream jobs to consume the new trigger outputs.
| ccip_changes: | ||
| - '**/*ccip*' | ||
| - '**/*ccip*/**' | ||
| file-sets: | |
There was a problem hiding this comment.
Do we have any tests on before-after for this?
There was a problem hiding this comment.
No.
- Could maybe retroactively compute them?
- Or I could run this in parrallel with existing logic, with this being more of a "no-op" and logging the run conditions as we roll it out?
I think the biggest benefit will come from ignoring core _test.go and testdata changes and deployment module changes when choosing what to run.
There was a problem hiding this comment.
I could run this in parrallel with existing logic, with this being more of a "no-op" and logging the run conditions as we roll it out?
This is what I did for changed-modules-go, and was able to validate it well enough. I think I will switch it to this.
Changes
dorny/paths-filterto new actionadvanced-triggersNotes
Related to #21659, #21685
DX-3534