[improve][ci] Skip detecting changed files in fork repositories

[BewareMyPower]

Motivation

In a private fork repository, the precondition workflow of a PR will always fail due to the lack of the permission to fetch the content of that PR.

Fetching list of changed files for PR#208 from Github API
  Invoking listFiles(pull_number: 208, per_page: 100)
Error: Resource not accessible by integration

Modifications

Only run the "Detect changed files" step and steps that depend on that step in the Apache repo.

Verifying this change

After applying this patch, the precondition workflows succeeded and the tests were executed.

Documentation

• doc
• doc-required
• doc-not-needed
• doc-complete

Matching PR in forked repository

PR in forked repository:

[lhotari]

The problem with the changes in this PR is that it would make it harder to develop the workflow in a public forked repository.

We should first investigate if there's a way to add permissions to the workflow. I'll provide more details soon.

[lhotari]

Is there a way where explicit job permissions specified with https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs would address the issue?

[BewareMyPower]

The problem with the changes in this PR is that it would make it harder to develop the workflow in a public forked repository.

The main affect is the PRs that only modify the documents will still trigger the unit tests. However, as the pulsar-site repository was already moved out of the main repo, such PRs are becoming much less than before. So I don't think it actually makes development harder in a public forked repository. I'm also suspicious about if there is a real developer that gets benefits from such savings of GitHub actions resources.

On the other hand, without this PR or another solution, the development in a private fork could be very hard. A PR needs to modify the workflow or the master branch needs to include a commit that removes these workflows to have tests executed.

We should first investigate if there's a way to add permissions to the workflow.

Technically it's right. But the paths-filter plugin is hard to maintain for contributors not familiar with JavaScript and GitHub actions.

[lhotari]

Technically it's right. But the paths-filter plugin is hard to maintain for contributors not familiar with JavaScript and GitHub actions.

there's no need to modify the paths-filter action when defining GitHub Actions workflow or job permissions. It's also possible that private repositories have a setting that makes the default permissions just work without any changes.

Explained in "Enforcing a policy for workflow permissions in your enterprise":

Anyone with write access to a repository can modify the permissions granted to the GITHUB_TOKEN, adding or removing access as required, by editing the permissions key in the workflow file. For more information, see permissions.

[BewareMyPower]

I also found another permission issue in the Semantic Pull Request / Check pull request title workflow though it does not block the development.

Run amannn/[email protected]
Error: Resource not accessible by integration

Mark this PR as drafted first because I don't have much time on it.

As a workaround to unblock the development, I will commit this patch in an independent development branch in the private forked repository.

[lhotari]

experiment in #22568 in draft mode