ci: build and smoke-test pushes and pull requests

[widgetii]

Adds the ci.yml caller, the same as openipc-hisilicon's. It runs build-xm.yml@openipc (#14) on github.sha, so pushes and PRs to openipc-xm are built and smoke-tested under qemu-hisilicon. It never releases; the workflow uploads only on dispatch. This PR's own run is the first CI run of the branch.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Run XM builds and smoke tests on pushes and pull requests

⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Add CI for pushes and pull requests targeting openipc-xm.
• Build the pushed commit or pull-request merge commit through the reusable XM workflow.
• Smoke-test builds under qemu-hisilicon without triggering release uploads.

Diagram

sequenceDiagram
    actor GH as GitHub Actions
    participant CI as CI caller
    participant Build as XM build
    participant QEMU as qemu-hisilicon
    GH->>CI: Push or PR
    CI->>Build: github.sha at openipc
    Build->>QEMU: Build and smoke-test
    QEMU-->>Build: Test result
    Build-->>GH: CI status

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Separate build and release reusable workflows

• ➕ Could allow CI callers to use read-only permissions instead of granting release-capable permissions.
• ➖ Requires refactoring the existing reusable workflow on the openipc branch.

Recommendation: Use the small caller for this PR: it reuses the existing build and smoke-test path, whose uploads are limited to dispatch. Separating build from release is worth considering later to reduce the caller's contents:write and id-token:write grants.

Files changed (1) +25 / -0

Other (1) +25 / -0

ci.ymlTrigger reusable XM CI for pushes and pull requests +25/-0

Trigger reusable XM CI for pushes and pull requests

• Adds a caller for events targeting openipc-xm and passes github.sha to build-xm.yml on the openipc branch. Grants the permissions required to validate the called workflow, while release uploads remain limited to dispatch within that workflow.

.github/workflows/ci.yml

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Pull requests can request identity tokens 🐞 Bug ⛨ Security

Description

The build job grants id-token: write and contents: write to the reusable workflow on both
push and pull_request events, although this caller does not dispatch a release. For a pull
request targeting openipc-xm, the called workflow has permission to request an identity token; the
stated upload guard does not restrict that permission.

Code

.github/workflows/ci.yml[R23-25]

+    permissions:
+      contents: write
+      id-token: write

Evidence

The trigger includes pull requests, while the same reusable-workflow call receives both elevated
permissions. The build inputs are selected from the triggering commit or pull-request merge;
restricting uploads to dispatch does not restrict the permissions granted to the called workflow.

.github/workflows/ci.yml[8-12]
.github/workflows/ci.yml[14-25]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The CI caller grants publish-level permissions to the reusable workflow during pull-request builds, even though this caller is not intended to publish.
## Fix Focus Areas
- .github/workflows/ci.yml[14-25]
## Recommended Fix
Separate the reusable workflow's build and publish paths so this caller can invoke the build path with read-only contents permission and without ID-token permission. Keep elevated permissions on the dispatch-only publishing path.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can see how risky a PR is at a glance with blast radius labels

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

1. Pull requests can request identity tokens 🐞 Bug ⛨ Security

The build job grants id-token: write and contents: write to the reusable workflow on both
push and pull_request events, although this caller does not dispatch a release. For a pull
request targeting openipc-xm, the called workflow has permission to request an identity token; the
stated upload guard does not restrict that permission.

Agent Prompt

## Issue description
The CI caller grants publish-level permissions to the reusable workflow during pull-request builds, even though this caller is not intended to publish.

## Fix Focus Areas
- .github/workflows/ci.yml[14-25]

## Recommended Fix
Separate the reusable workflow's build and publish paths so this caller can invoke the build path with read-only contents permission and without ID-token permission. Keep elevated permissions on the dispatch-only publishing path.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools