Skip to content

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.

Sign up for GitHub

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

Open
simonbeaudoin0935 wants to merge 2 commits into
base: development
Choose a base branch
from
Open

Add workflow to trigger a build of the package repo #251

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
9aae663
Add workflow to trigger a build of the package repo
simonbeaudoin0935 Oct 19, 2025
914cf34
Add concurrency guard and remove security-events write
simonbeaudoin0935 Dec 1, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 34 additions & 0 deletions .github/workflows/pkg-build-pr-check.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@

name: Package Build PR Check
description: |
This workflow will execute when a PR is open against the configured branch.
On top of whatever kind of CI/CD logic happens in this upstream repo, this
workflow will make sure that what is attempted to be merged in the main release
branch won't break the debian package. The variable PKG_REPO_GITHUB_NAME needs to
be set in the repo where this file reside. This variable hold the packaging repo
name on github associated to this upstream repo. What will happen is that the PR
triggering this workflow will go knock on the packaging repo's door and trigger
a full build of the package if it were to include these changes.

on:
pull_request_target:
Copy link
Contributor

@ekanshibu ekanshibu Nov 27, 2025

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.

Copy link
Author

@simonbeaudoin0935 simonbeaudoin0935 Dec 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a habit of using 'pull_request_target' for security reason, so running the PR with the workflow from the basebranch, but using the content of the PR branch with the "upstream-repo-ref: ${{github.head_ref}}". What this does is that in the qcom-upstream-pr-pkg-build-reusable-workflow.yml reusable withflow, I checkout the content of the PR

branches: [ main, development ]

permissions:
contents: read

concurrency:
group: pr-${{ github.event.pull_request.number }}
cancel-in-progress: true

jobs:
package-build-pr-check:
Copy link
Contributor

@ekanshibu ekanshibu Nov 27, 2025

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

Copy link
Author

@simonbeaudoin0935 simonbeaudoin0935 Dec 1, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, thats not a bad idea, but it seems like its not possible to add it here when using a reusable workflow, it would have to be in a job with the steps: statement, aka inside the reusable workflow

uses: qualcomm-linux/qcom-build-utils/.github/workflows/qcom-upstream-pr-pkg-build-reusable-workflow.yml@main
with:
qcom-build-utils-ref: main
upstream-repo: ${{github.repository}}
upstream-repo-ref: ${{github.head_ref}}
pkg-repo: ${{vars.PKG_REPO_GITHUB_NAME}}
pr-number: ${{github.event.pull_request.number}}
secrets:
TOKEN: ${{ secrets.DEB_PKG_BOT_CI_TOKEN }}
Loading