ci: GitHub Actions workflow (build, lint, test) [RHIDP-14958]

[johnmcollier]

Summary

• Adds .github/workflows/ci.yml triggered on push to main and all PRs targeting main
• Single job: Node.js 22 on ubuntu-latest, steps: npm ci → npm run build → npm run lint → npm test
• Dependency cache keyed on package-lock.json via actions/setup-node@v4 cache: npm — no manual cache step needed
• Concurrency group cancels in-progress runs when a new commit arrives on the same ref (avoids queue buildup on active PRs)

Jira

• Task: RHIDP-14958
• Epic: RHIDP-14946 — RHESS: Project Scaffold & Repository Interfaces
• Feature: RHDHPLAN-1525

Test plan

• CI run triggers on this PR and all steps pass (install, build, lint, test)
• A subsequent push to this branch cancels the previous run (concurrency)

Notes

Once merged, all future PRs will have CI gating. Branch protection rules on main can be configured to require this check.

Made with Cursor

[qodo-code-review]

PR Summary by Qodo

Add GitHub Actions CI workflow for build, lint, and test
⚙️ Configuration changes ✨ Enhancement 🕐 Less than 10 minutes

Description

• Add GitHub Actions CI workflow triggered on pushes and PRs targeting main.
• Run npm ci, build, lint, and tests on ubuntu-latest with Node.js 22.
• Enable npm dependency caching and cancel superseded runs via concurrency.

Diagram

graph TD
  E1("push to main") --> WF[".github/workflows/ci.yml"] --> J["Job: ci"] --> R["Runner: ubuntu-latest"] --> N["setup-node (22)"] --> I["npm ci"] --> B["npm run build"] --> L["npm run lint"] --> T["npm test"]
  E2("PR to main") --> WF

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Split into separate jobs (build/lint/test)

• ➕ Clearer ownership and faster feedback if some stages can run in parallel
• ➕ Allows stage-specific timeouts and required checks
• ➖ More workflow complexity and potentially longer overall queue time
• ➖ Requires artifact sharing if build outputs are needed by tests

2. Use a Node version matrix (e.g., 20/22)

• ➕ Catches version-specific issues earlier
• ➕ Easier to evolve support policy explicitly
• ➖ Higher CI cost/time per PR
• ➖ More noise if the project only targets a single runtime

3. Pin runner image and action SHAs

• ➕ Improves supply-chain security and reproducibility
• ➖ More maintenance overhead to update pins regularly

Recommendation: The current single-job workflow is the right starting point: minimal complexity, standard npm caching via setup-node, and concurrency to avoid wasted cycles. Consider splitting jobs or adding a Node matrix once CI becomes a bottleneck or runtime support expands; consider SHA pinning if your org requires stricter supply-chain controls.

Files changed (1) +37 / -0

Other (1) +37 / -0

ci.ymlAdd CI workflow for Node build/lint/test with caching and concurrency +37/-0

Add CI workflow for Node build/lint/test with caching and concurrency

• Introduces a GitHub Actions workflow triggered on pushes and PRs to 'main'. Runs a single job on 'ubuntu-latest' using Node.js 22 with npm cache enabled, executing 'npm ci', 'npm run build', 'npm run lint', and 'npm test' in sequence. Adds concurrency to cancel in-progress runs for the same ref when new commits arrive.

.github/workflows/ci.yml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📎 Requirement gaps (0) 📜 Skill insights (0)

Context used

✅ Tickets: RHIDP-14958

1. Unpinned GitHub actions 🐞 Bug ⛨ Security

Description

The workflow uses actions/checkout@v4 and actions/setup-node@v4 by mutable tag, which can change
over time and could allow unexpected code execution if an upstream tag is compromised or retargeted.

Code

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

+      - uses: actions/checkout@v4
+
+      - name: Set up Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: "22"
+          cache: "npm"

Evidence

The workflow currently pulls actions by major-version tags rather than immutable SHAs.

.github/workflows/ci.yml[18-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 workflow references third-party actions by moving tags (`@v4`) instead of immutable commit SHAs, which is a supply-chain hardening risk.

### Issue Context
This repository’s CI executes on `push`/`pull_request`, so the action code is executed frequently and should be pinned to known-good revisions.

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

Pin each action to a full commit SHA (optionally keep the tag in a comment), e.g.:
- `uses: actions/checkout@<sha>`
- `uses: actions/setup-node@<sha>`

Optionally add Dependabot configuration to keep pinned SHAs updated.

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

---

2. No explicit token permissions 🐞 Bug ⛨ Security

Description

The workflow does not declare a permissions: block, so GITHUB_TOKEN privileges depend on
repository defaults while the job runs arbitrary project code (npm ci, npm run build/lint, `npm
test`).

Code

.github/workflows/ci.yml[R1-18]

+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+concurrency:
+  group: ci-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  ci:
+    name: Build, Lint & Test
+    runs-on: ubuntu-latest
+
+    steps:

Evidence

The workflow is triggered on PRs and runs npm commands, but it does not set permissions, meaning
token scope is not explicitly constrained in this workflow.

.github/workflows/ci.yml[3-8]
.github/workflows/ci.yml[1-18]
.github/workflows/ci.yml[27-37]
package.json[11-21]

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 workflow relies on implicit default `GITHUB_TOKEN` permissions. This is brittle (repo/org defaults can change) and increases risk if a future step inadvertently uses token write access.

### Issue Context
The job executes repository-controlled scripts (`build`, `lint`, `test`) on `pull_request` events.

### Fix Focus Areas
- `.github/workflows/ci.yml[1-37]`

Add an explicit permissions block, e.g. at workflow or job level:
```yaml
permissions:
 contents: read
```
Add additional permissions only if/when required by later steps (e.g., `pull-requests: read` if posting PR annotations).

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

---