Update qcom-preflight-checks.yml

[Sandhya1236]

Running untrusted code on the pull_request_target trigger may lead to security vulnerabilities. These vulnerabilities include cache poisoning and granting unintended access to write privileges or secrets.

https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull_request_target

We should update all usage of pull_request_target in all workflow files and also update qualcomm-preflight-check to the latest.

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[Sandhya1236]

CI failure is expected on fork PRs with pull_request

This job is failing at actions/checkout (before QC Preflight runs). The workflow is attempting to fetch the PR head repo (fork) and checkout fails with “Repository not found” / exit code 128 because the workflow token can’t access the fork in our internal/private setup.

This matches OSDO guidance in “OSS Ops Guidance:

https://github.qualcomm.com/OSDO/osdo.github.qualcomm.com/pull/212/files

Prefer splitting untrusted and trusted workflows:
Use pull_request for PR builds/tests (no secrets, read-only).
Move secret-dependent/privileged steps to trusted triggers (e.g. push to protected branches, workflow_dispatch, etc.).
Guiding principle: “Untrusted code and privileged access must never coexist in the same workflow.”
So the failure is due to GitHub’s fork PR permissions model after moving away from pull_request_target, not due to the changes in this PR.

[njjetha]

Changes look good, but the Repolinter and Copyright and License checks are failing.

[mynameistechno]

Changes look good, but the Repolinter and Copyright and License checks are failing.

This PR should not fail copyright check based on the PR changes alone. I see that both the pull_request and pull_request_target events ran and both failed, and the pull_request one is running the latest version of copyright license checker.

@targoy-qti @njjetha is this related to the way the diff is calculated?

The repolinter check was already failing on 3 files:

✖ camera_kt/drivers/cam_sensor_module/cam_ir_led/cam_ir_led_core.c: The first 200 lines do not contain the pattern(s): SPDX-License-Identifier|Redistribution and use in source and binary forms, with or without
✖ camera_kt/drivers/cam_sensor_module/cam_ir_led/cam_ir_led_dev.c: The first 200 lines do not contain the pattern(s): SPDX-License-Identifier|Redistribution and use in source and binary forms, with or without
✖ camera_kt/drivers/cam_sensor_module/cam_ir_led/cam_ir_led_soc.c: The first 200 lines do not contain the pattern(s): SPDX-License-Identifier|Redistribution and use in source and binary forms, with or without

@gkhose-qipl FYI are these QC-authored files?

[njjetha]

Changes look good, but the Repolinter and Copyright and License checks are failing.

This PR should not fail copyright check based on the PR changes alone. I see that both the pull_request and pull_request_target events ran and both failed, and the pull_request one is running the latest version of copyright license checker.

@targoy-qti @njjetha is this related to the way the diff is calculated?

The repolinter check was already failing on 3 files:

✖ camera_kt/drivers/cam_sensor_module/cam_ir_led/cam_ir_led_core.c: The first 200 lines do not contain the pattern(s): SPDX-License-Identifier|Redistribution and use in source and binary forms, with or without
✖ camera_kt/drivers/cam_sensor_module/cam_ir_led/cam_ir_led_dev.c: The first 200 lines do not contain the pattern(s): SPDX-License-Identifier|Redistribution and use in source and binary forms, with or without
✖ camera_kt/drivers/cam_sensor_module/cam_ir_led/cam_ir_led_soc.c: The first 200 lines do not contain the pattern(s): SPDX-License-Identifier|Redistribution and use in source and binary forms, with or without

@gkhose-qipl FYI are these QC-authored files?

@mynameistechno diff should only take the file changes which are in PR. qualcomm/qcom-reusable-workflows#25 calculate the correct diff.

[mynameistechno]

@mynameistechno diff should only take the file changes which are in PR. qualcomm/qcom-reusable-workflows#25 calculate the correct diff.

@targoy-qti do we need this fix qualcomm/qcom-reusable-workflows#25 then?

I.e. why is copyright license checker complaining about these files

if this PR only touches .github/workflows/qcom-preflight-checks.yml?

[targoy-qti]

@mynameistechno diff should only take the file changes which are in PR. qualcomm/qcom-reusable-workflows#25 calculate the correct diff.

@targoy-qti do we need this fix qualcomm/qcom-reusable-workflows#25 then?

I.e. why is copyright license checker complaining about these files

if this PR only touches .github/workflows/qcom-preflight-checks.yml?

Yes, this needs to be fixed. It’s a bit odd that the issue showed up after a year of deployment, but thanks to Neeraj for already picking it up
@njjetha can we continue on qualcomm/qcom-reusable-workflows#25?