[full-ci] chore: [OCISDEV-790] add ci-full flag

[mzner]

Description

Introduces a check-flags job to the GitHub Actions test workflow that gates downstream jobs based on changed file paths and an opt-in full-ci flag in the PR title.

Changes:

• New check-flags job runs before all other jobs and produces three outputs:
  • full-ci: true when the PR title contains full-ci (case-insensitive)
  • ci-relevant: true when files relevant to CI (packages, tests, config files, etc.) were changed
  • affected-suites: the subset of test suites affected by the changed files, determined via filterTestSuitesToRun.js
• The build job is now skipped on PRs when no CI-relevant files changed and full-ci is not set
• The e2e-playwright job skips individual test suites when they are not in the affected suites list
• Two suites (app-provider, ocm) are marked requires_full_ci: true and only run when full-ci is explicitly requested
• check-tests-passed now also depends on build

Related Issue

• Fixes https://kiteworks.atlassian.net/browse/OCISDEV-790

Motivation and Context

CI runs on every PR are time-consuming and resource-intensive. Previously all jobs ran regardless of which files were changed. This change makes jobs conditional on the actual changes in the PR, while providing a full-ci opt-in in the PR title for cases where complete coverage is required.

How Has This Been Tested?

• test environment: GitHub Actions (PR workflow)
• test case 1: PR with no CI-relevant file changes → build and e2e-playwright jobs are skipped
• test case 2: PR with changes to source packages → only affected test suites are executed
• test case 3: PR title includes full-ci → all jobs and suites run unconditionally
• test case 4: Push/tag event → all jobs run as before

Screenshots (if appropriate):

N/A

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[LukasHirt]

In drone, we were using filterTestSuitesToRun.js to find what tests should run. If you find the current approach works better I am fine with not using that but I would:

1. check whether the result is the same
2. if it won't be used anymore, delete it

Also, if we go with this approach, the GH action needs to be whitelisted.

[LukasHirt]

Seems like there is still some action needing to be whitelisted.

[mzner]

Seems like there is still some action needing to be whitelisted.

I'm waiting for your approval here first before asking Thomas to white list it.

[LukasHirt]

I'm waiting for your approval here first before asking Thomas to white list it.

It would be best to first see the CI running here to see whether it works as expected. I would approve the code as it is now but waiting for the successful run is necessary.

[mzner]

@PrajwolAmatya Could you please confirm the changes in this commit? Some of the latest changes we have in this commit "9bd7e30" broke the ci cause the filter test js file was not updated.

[sonarqubecloud]

Quality Gate passed

Issues
10 New issues
0 Accepted issues

Measures
9 Security Hotspots
63.8% Coverage on New Code
1.0% Duplication on New Code

See analysis details on SonarQube Cloud