-
Notifications
You must be signed in to change notification settings - Fork 50
Add workflow to trigger a build of the package repo #251
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: development
Are you sure you want to change the base?
Add workflow to trigger a build of the package repo #251
Conversation
This workflow is an adapted copy of this workflow : https://github.com/qualcomm-linux/pkg-template/blob/main/.github/workflows/to_paste_in_upstream/pkg-build-pr-check.yml With this workflow in position, a PR in the upstream project repo (this one) triggers a build or the sister package repo. The special repo variable PKG_REPO_GITHUB_NAME will need to be set. See visit https://github.com/qualcomm-linux/pkg-template for more info about this whole CI workflow Signed-off-by: Simon Beaudoin <[email protected]>
|
|
||
| permissions: | ||
| contents: read | ||
| security-events: write |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why security-events need to have write permissions? Is there any code scanning happening with this workflow?
| permissions: | ||
| contents: read | ||
| security-events: write | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is concurrency check also needed here? Say if multiple PR updates happen quickly?
| a full build of the package if it were to include these changes. | ||
|
|
||
| on: | ||
| pull_request_target: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should it be pull_request instead of pull_request_target? Or is it intended to run the workflow against the base repo instead of the PR's repo? I'm assuming this workflow is intended for all the PRs that are getting raised for this project.
| security-events: write | ||
|
|
||
| jobs: | ||
| package-build-pr-check: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
adding timeout-minutes here might help to avoid stuck runners
This workflow is an adapted copy of this workflow : https://github.com/qualcomm-linux/pkg-template/blob/main/.github/workflows/to_paste_in_upstream/pkg-build-pr-check.yml
With this workflow in position, a PR in the upstream project repo (this one) triggers a build or the sister package repo (in this case, it will be https://github.com/qualcomm-linux/pkg-fastrpc). The special repo variable PKG_REPO_GITHUB_NAME will need to be set to "qualcomm-linux/pkg-fastrpc" in this repo for this to work.
See visit https://github.com/qualcomm-linux/pkg-template for more info about this whole CI workflow.
When a PR is open in this repo, this workflow will in turn call this one :
https://github.com/qualcomm-linux/qcom-build-utils/blob/main/.github/workflows/qcom-upstream-pr-pkg-build-reusable-workflow.yml
What it will do is try to compile the debian package from the "qualcomm-linux/pkg-fastrpc" but with the changes from the PR opened on this side added in order to test that the debian package will still build if this PR were to be merged.
Ultimately, there will be even more tests downstream from that, like integration tests in a whole distro.