ci: build-test PRs with existing pipeline in main branch - #77
Conversation
07961f9 to
8ed08a1
Compare
|
All we need is a premerge yml in qcom/debian/latest (example) that calls to daily yml on pull_request, and daily needs to have workflow_call inputs to be used as reusuable workflow. Daily yml then will automatically parse all matrix variants specifications, and it will delegate to build-kernel-deb, which then delegates to build-kernel-debusine (debian family) AND build-kernel-ubuntu (ubuntu family). To initiate the whole chain, all is needed is a call to daily. |
8ed08a1 to
71e8232
Compare
c7dc24b to
7df95c4
Compare
82ea74d to
e9acde3
Compare
|
No concurrency group on this one, so every push to a PR fires another 5 kernel builds and the in-flight ones keep running on the self-hosted pool. The example from the premerge on pkg-linux-qcom-canonical guards it with: concurrency:
group: pr-build-${{ github.event.pull_request.number }}
cancel-in-progress: trueWorth adding here too? |
pkg-pr-hook.yml delegated to pkg-build-reusable-workflow.yml, which runs generate-source-package immediately after checkout. That needs a real debian/changelog, but this branch ships changelog.in and only "debian/rules prepare" generates it, inside a kernel tree, since it reads the version from the kernel Makefile. So the build never started. The main branch already has a workflow that does all of this: daily.yml already runs it nightly. Reuse that workflow for PRs. Closes: #75 Signed-off-by: Christopher Obbard <[email protected]>
e9acde3 to
a701a25
Compare
Bjordis Collaku (bjordiscollaku)
left a comment
There was a problem hiding this comment.
Looks good.
8cd25bb
into
qcom/debian/latest
Closes: #75