Remove duplicate "skip" workflows from CI, now skipping jobs inside of the same workflows

[jormundur00]

What does this PR do?

This PR removes the duplicate “skip” workflows that existed only to report successful checks when no relevant files changed. Previously, each CI workflow had a corresponding “skip” workflow, doubling the number of workflow files and cluttering the GitHub Actions page.

This PR consolidates the skip logic inside individual jobs and steps using the in-repo detect-file-changes action. With this change:

• The workflows always trigger (e.g., on pull requests)
• Relevant file checks are performed inside the job itself using the detect-file-changes step
• Subsequent steps within the job are skipped if no relevant files changed, but the job itself still completes successfully
• Branch protection rules and required workflow jobs are satisfied
• The CI still clearly reports that the workflow ran and which steps were skipped intentionally

This simplifies workflow maintenance, reduces visual clutter in the Actions UI, and preserves accurate reporting of required jobs.

Fixes: #791

[jormundur00]

Currently, all new workflows don't run because of the need to whitelist dorny/paths-filter github action.

The error is:

The action dorny/paths-filter@v3 is not allowed in oracle/graalvm-reachability-metadata because all actions must be from a repository owned by your enterprise, created by GitHub, or match one of the patterns: aquasecurity/setup-trivy*, aquasecurity/trivy-action*, docker/*, gradle/actions/wrapper-validation*, gradle/wrapper-validation-action*, microsoft/[email protected], ossf/scorecard-action*, ruby/setup-ruby*, slsa-framework/slsa-github-generator*.

Also, we should probably consider adding the jobs 📋 Get a list of libraries to test for build-logic changes and 🧪 All build-logic triggered tests have passed to the list of required/expected jobs, as the whole reason we had this skip.yml logic was so we always run a version of these tests (so having them be not required makes no sense).

[vjovanov]

Can we generate a simplified version of this action in this repo?

[jormundur00]

Can we generate a simplified version of this action in this repo?

I’ve created a minimal in-repo version of this action that covers only the specific use-cases we need, rather than the full paths-filter action. I’ve tested all relevant scenarios on a fork—since this PR only modifies files related to the checkstyle workflow.

[vjovanov]

Maybe call it better than action.yml?

[jormundur00]

The yml file that designates an action must be named action.yml (or action.yaml, see).

[vjovanov]

Add comments and examples.

[vjovanov]

Also, give it a better name.

[jormundur00]

Renamed it to detect-file-changes.js (like the action itself). Also, added documentation and example to the js.

[vjovanov]

Did you test on forks, and regular branches?

[jormundur00]

I've tested it on a fork, opening a pull request to the master branch of the fork (with different combinations of changed files). These workflows are ran only on pull_request (an exception being scan-docker-images.yml also running on schedule), so only creating a branch doesn't run them (given the on: pull_request: rules still being set, like they currently are on master, just without filters).

P.S: test-changed-metadata and test-changed-infrastructure only run their actual tests if github.repository == 'oracle/graalvm-reachability-metadata', so I manually changed these on the fork to test functionality.