[github-action] limit changed files for pull requests

[hgy59]

Motivation: Avoid the need of rebase to master to get only changed files on branch

• use diff with three dots to limit changed files to branch

[hgy59]

@publicarray I just updated the detection of changed files to limit to files modified on the branch.

I did this for pull_request only, and I am asking now for the use case with push.

• What is your intention behind the step called Get changed files for push?
• How is this related to setting a tag?
• Is this for tags on the master branch only, what is the expected format of tags and which packages are built for such tags?

[publicarray]

Hey @hgy59!

Nice, Sometimes I feel like a git noob...

• What is your intention behind the step called Get changed files for push?

I add commits on my branch/fork directly so a push makes sure the Action is run after a push not just on a pull request. I added the pull-request step after I realised that push would not work on pull requests.

• How is this related to setting a tag?

Only that tag is also a push and needs to filtered using an if

• Is this for tags on the master branch only, what is the expected format of tags and which packages are built for such tags?

Once a tag (on any branch that has the workflow file) is made e.g. package-name-version (the last - separates the version from the name) the action will build the requested package (spk/package-name) and upload the spk files to the Github release. See my repo as an example: https://github.com/publicarray/spksrc/releases.

It's very useful for people that want to create their own builds with a fork.

[hgy59]

Nice, Sometimes I feel like a git noob...

Who said git noob? I never heard of three-dot before, and the challenge was to search the net for "diff changes on branch only..." (and I had my first git rebase training lately in PR #3648).

I add commits on my branch/fork directly so a push makes sure the Action is run after a push not just on a pull request. I added the pull-request step after I realised that push would not work on pull requests.

Just to clarify: After the creation of a PR every push will trigger the action with pull_request.
May be the behaviour is different for working on a local fork only (without/before creation of a PR).

Only that tag is also a push and needs to filtered using an if
...
Once a tag (on any branch that has the workflow file) is made e.g. package-name-version (the last - separates the version from the name) the action will build the requested package (spk/package-name) and upload the spk files to the Github release. See my repo as an example: https://github.com/publicarray/spksrc/releases.
...
It's very useful for people that want to create their own builds with a fork.

Aaah, I supposed that such tags would create a release that is published to packages.synocommunity.
Can we limit this to forks?
Or (cc: @ymartin59) does it make sense to use this feature to provide pre-releases in the main repository?

[ymartin59]

@hgy59 It is a "good idea" to review changes from common ancestor to determine impact packages/libraries. The same way GitHub displays files in PR.
Technically speaking, GitHub actions should not only test build process from branch itself, but also on a local workspace where branch is merged to PR target branch (master but may be anyone else) - because packages may be built and published from master after merge.