.github/workflows/build.yml: Add GitHub actions for building QubesOS …

[krystian-hebel]

…packages

[krystian-hebel]

Requires TrenchBoot/.github#1 to be merged first.

[SergiiDmytruk]

I wonder why GitHub doesn't show CI runs for this PR. Conditions are satisfied, so it should try to run CI here.

[krystian-hebel]

It doesn't because there are not satisfied on main, it seems that only the target branch matters in this case. They can be forced by adding pull_request, which is (in addition to forced branch on https://github.com/TrenchBoot/.github) what I did to get https://github.com/TrenchBoot/qubes-antievilmaid/actions/runs/6352630738

[SergiiDmytruk]

Hm, I thought the difference between pull_request and pull_request_target is in what branch name is matched against patterns (PR's or PR's target) which is wrong, it's about where to get configuration data.

I added filters for xen and grub because there are multiple branches some of which aren't related to AEM, maybe here that's not needed and all pushes can be handled. Or keep it as as because after merging the PR future PRs should be run on CI as well, but testing CI changes will be harder.

[krystian-hebel]

I think it still is how you describe it, except that pull_request_target is fired on the target branch, with all its files, which includes CI settings.

I can change it for this repo, it's not like there is much compilation to do for this component anyway.

[krystian-hebel]

Everything seems to be working. I removed push because it ran CI twice, and pull_request should include everything we need anyway, according to https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request:

For example, if no activity types are specified, the workflow runs when a pull request is opened or reopened or when the head branch of the pull request is updated.