Added testbuild tag to trigger Actions -pipeline

[tqre]

The 'testbuild' tag can be used to trigger the GitHub Actions workflow. It can be used to build and run on any update, and the main point is that releases are only created on pushes to the master branch.

Usage: create a tag and push a new branch with an update to a package $ git tag testbuild-package-version $ git push -u origin branch testbuild-package-version

The testbuild-package-version is the tag. The naming reflects also on the Actions -page: https://github.com/tqre/selinux/actions/runs/490600535

[tqre]

Turned out tags worked differently than I thought - they are unique and point to a certain commit. I corrected the workflow on the first post, so each tag has to be created and pushed to the testing fork.

Any better solution is of course welcome, but the main idea works: testing pushes are built but not released.

[fishilico]

I was thinking: why is the GitHub Action workflow only running and testing master (and github-actions, which was for testing and which could be removed from the config)? The more I read about GitHub Actions, the more I feel that a "more intuitive way" consists in building on all pushes and Pull Requests, and only releasing when github.ref == 'refs/heads/master'.

In order to see whether I missed something, I am testing:

on:
  push:
  pull_request:
  workflow_dispatch:

in https://github.com/fishilico/arch-selinux/commit/c848104ecfd47c2cc9ee0519c855688b5406a991

[tqre]

I see your point and it makes sense, it could be run on pushes to any branch or on any pull request and release only on master pushes. It's also a kind of leftover from testing, but I left it there as I think it is good to control the workflow triggers, but that's just me. Which actually raises a question, how does the pipeline trigger when a branch that has a different GH-actions file inside?

Also as the tags didn't work as I envisioned originally, more simple and straightforward way is what I prefer too in the end.

The paths I included because they are the files that are involved and affect the build process. No need to run the pipeline on readme updates, right?

[fishilico]

Which actually raises a question, how does the pipeline trigger when a branch that has a different GH-actions file inside?

If I understood correctly, for workflows triggered by on: pull_request, the workflow configuration from the fork/incoming branch is used (contrary to on: pull_request_target), and no repository secret is shared with the workflow (otherwise, it could be a security issue).

The paths I included because they are the files that are involved and affect the build process. No need to run the pipeline on readme updates, right?

Such updates are quite uncommon, and I prefer not missing a file that matters for the build, in the filter of the workflow. So I am not convinced filtering on the paths bring more advantages than disadvantages.

I created https://github.com/archlinuxhardened/selinux/pull/77 with my suggestion, and https://github.com/archlinuxhardened/selinux/pull/78 as an example of CI on a package update. Does this look good to you?

[tqre]

Closing this one, as #77 replaces this.