feat(ci): Add reusable GitHub actions for CI setup; Bump actions/checkout to v6.0.2.#110
Conversation
WalkthroughAdds five reusable GitHub composite actions (install-go-task, install-python, install-uv, install-java, print-tool-versions) and updates two CI workflows to use these local actions instead of inline installation commands. Changes
Sequence Diagram(s)sequenceDiagram
participant Workflow as "GitHub Workflow"
participant Composite as "Local Composite Action"
participant Upstream as "Pinned Upstream Action"
participant Runner as "Runner (shell)"
rect rgba(200,220,255,0.5)
Workflow->>Composite: call ./exports/.../install-go-task (version)
Composite->>Upstream: uses go-task/setup-task@<commit> (with.version)
Upstream->>Runner: install go-task on runner
Runner-->>Upstream: install result
Upstream-->>Composite: success/failure
Composite-->>Workflow: step result
end
rect rgba(200,255,220,0.5)
Workflow->>Composite: call ./exports/.../print-tool-versions
Composite->>Runner: run loop (tool --version || echo "not found")
Runner-->>Composite: versions output
Composite-->>Workflow: printed tool versions
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@exports/github/actions/install-go-task/action.yaml`:
- Around line 13-16: Update the macOS install step (the job entry with if:
"'macOS' == runner.os" and name "Install coreutils (for md5sum)") to first check
whether md5sum is already available and only run brew install coreutils when it
is missing; change the run field to perform a command existence check (e.g., use
command -v or which for md5sum) and conditionally invoke brew install coreutils
to avoid unnecessary installs and CI latency/failures.
In `@exports/github/actions/log-tool-versions/action.yaml`:
- Around line 19-24: The loop that runs each tool's version ("while IFS= read -r
tool; do" / the invocation "${tool}" --version) can fail the step if a tool
returns non-zero; make the version check best-effort by suppressing non-zero
exits for the version command (e.g., run the "${tool}" --version invocation in a
way that ignores its exit code or append a fallback like "|| true"), and
optionally emit a clear diagnostic when the version command fails so the loop
continues rather than aborting the job.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: a043c97b-1e6f-442f-82d4-67acebdc069f
📒 Files selected for processing (4)
exports/github/actions/install-go-task/action.yamlexports/github/actions/install-python/action.yamlexports/github/actions/install-uv/action.yamlexports/github/actions/log-tool-versions/action.yaml
actions/checkout to v6.0.2.
There was a problem hiding this comment.
Iirc doesn't uv manage/setup the python version to run? If we have uv do we still need to manually install python?
There was a problem hiding this comment.
I think some repos still directly use python3/python3 -m venv instead of uv for some of the task workflows. uv is definitely nicer but not yet standardized.
There was a problem hiding this comment.
We should discuss more with multiple people, but we might want to manually install uv through our tasks similar to what CLP does with rust (also that toolchain code probably should be moved to dev-utils).
In other words, for tools such as rust and uv that are "easy" for us to manage ourselves we can create tasks to install and setup the environment so that both local builds and CI can benefit.
These CI actions would be reserved for tools we expect the user to deal with themselves.
There was a problem hiding this comment.
We already have scripts to install cmake, task, and uv via pipx (see my pending PR: https://github.com/y-scope/clp/pull/1320/changes). The main advantage of pipx is that it avoids modifying system directories. By prepending the pipx bin path to PATH, we can ensure those versions take priority.
Similarly, using GitHub Actions to set up these tools removes the need to worry about runner environment differences, user and group handling, figuring out which parts of our scripts to run, or invoking sudo.
Furthermore, the setup-task and setup-uv actions are published by their respective maintainers, so they are generally reliable and safe to depend on.
There was a problem hiding this comment.
FYI we are also adding nodejs to the toolchains.
There was a problem hiding this comment.
@coderabbitai Open an issue for this discussion.
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
gh issue create \
--repo y-scope/yscope-dev-utils \
--title "feat: Evaluate task-based tool installation vs. GitHub Actions for tools like uv and nodejs" \
--assignee "Bill-hbrhbr" \
--body "## Summary
A discussion in `#110` raised the question of whether tools like \`uv\` (and potentially \`nodejs\`) should be installed via [task](https://taskfile.dev/) scripts rather than dedicated GitHub composite Actions.
## Context
In [`#110` (comment)](https://github.com/y-scope/yscope-dev-utils/pull/110#discussion_r3040110941), `@davidlion` suggested that for tools which are relatively easy for us to manage ourselves (e.g., \`uv\`, \`rust\`), we could create task scripts to install and set up the environment — similar to how [CLP handles rust](https://github.com/y-scope/clp/blob/main/taskfiles/toolchains.yaml#L57). This approach would benefit both local builds and CI pipelines equally, while CI composite actions would be reserved for tools that users are expected to manage themselves.
`@davidlion` also noted that the toolchain code from CLP probably should eventually be moved into \`yscope-dev-utils\`.
`@Bill-hbrhbr` noted several advantages of the current approach using \`pipx\` and GitHub Actions (see [CLP `#1320`](https://github.com/y-scope/clp/pull/1320/changes)):
- \`pipx\` avoids modifying system directories; prepending the pipx bin path to \`PATH\` ensures correct version priority.
- GitHub Actions remove the need to handle runner environment differences, user/group handling, partial script invocation, and \`sudo\`.
- \`setup-task\` and \`setup-uv\` are published by their respective maintainers, making them reliable dependencies.
Additionally, \`nodejs\` is being considered for addition to toolchains.
## Discussion Points
- Should tools like \`uv\` be installed via task scripts to unify local and CI setup?
- Which tools are best managed via GitHub composite Actions vs. task scripts?
- Should CLP's toolchain task scripts be migrated to \`yscope-dev-utils\`?
## References
- PR: https://github.com/y-scope/yscope-dev-utils/pull/110
- Discussion comment: https://github.com/y-scope/yscope-dev-utils/pull/110#discussion_r3040110941
- CLP toolchains reference: https://github.com/y-scope/clp/blob/main/taskfiles/toolchains.yaml#L57
- CLP PR with pipx-based install: https://github.com/y-scope/clp/pull/1320/changes
Opened by `@Bill-hbrhbr`."
Length of output: 54
@Bill-hbrhbr, I've opened a new issue to track this discussion: #111
The issue captures:
@davidlion's suggestion to use task-based installation for "easy" tools likeuv(similar to CLP's rust toolchain), benefiting both local and CI builds.- Your points on the advantages of
pipxand GitHub Actions (nosudo, no runner environment concerns, maintainer-published actions). - The potential migration of CLP's toolchain task scripts into
yscope-dev-utils. - The consideration of adding
nodejsto toolchains.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@exports/github/actions/install-java/action.yaml`:
- Around line 20-21: Update the template expressions used for the distribution
and java-version inputs to use the idiomatic GitHub Actions spacing: change
`${{inputs.distribution}}` to `${{ inputs.distribution }}` and
`${{inputs.version}}` to `${{ inputs.version }}` in the action.yaml so the keys
distribution and java-version reference inputs with the spaced `${{ ... }}`
format for readability and consistency.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: a867df3b-3cef-4c14-9343-e0f0ec37f7ed
📒 Files selected for processing (5)
.github/workflows/code-linting-checks.yaml.github/workflows/unit-tests.yamlexports/github/actions/install-go-task/action.yamlexports/github/actions/install-java/action.yamlexports/github/actions/print-tool-versions/action.yaml
There was a problem hiding this comment.
♻️ Duplicate comments (1)
exports/github/actions/print-tool-versions/action.yaml (1)
26-29:⚠️ Potential issue | 🟡 MinorDifferentiate “not found” from “version check failed”.
At Line 28, every non-zero from
--versionis reported asnot found, which can hide real tool/runtime issues.♻️ Suggested fix
while IFS= read -r tool; do - if ! "${tool}" --version; then - echo "${tool} not found" + if command -v "${tool}" >/dev/null 2>&1; then + if ! "${tool}" --version; then + echo "${tool} --version failed" + fi + else + echo "${tool} not found" fi done <<< "${TOOLS}"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@exports/github/actions/print-tool-versions/action.yaml` around lines 26 - 29, The loop currently treats any non-zero exit from running "${tool}" --version as "not found"; first test existence of the executable (e.g., use command -v or type to check "${tool}") and only print "${tool} not found" when that check fails, otherwise run "${tool} --version" and, if it returns non-zero, print a different message like "${tool} version check failed" (apply this change around the while loop and the if that invokes "${tool}" --version to separate existence check from version-check failures).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@exports/github/actions/print-tool-versions/action.yaml`:
- Around line 26-29: The loop currently treats any non-zero exit from running
"${tool}" --version as "not found"; first test existence of the executable
(e.g., use command -v or type to check "${tool}") and only print "${tool} not
found" when that check fails, otherwise run "${tool} --version" and, if it
returns non-zero, print a different message like "${tool} version check failed"
(apply this change around the while loop and the if that invokes "${tool}"
--version to separate existence check from version-check failures).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 7b4a8b74-52c7-4e9c-941d-fe6e4c6927ce
📒 Files selected for processing (5)
exports/github/actions/install-go-task/action.yamlexports/github/actions/install-java/action.yamlexports/github/actions/install-python/action.yamlexports/github/actions/install-uv/action.yamlexports/github/actions/print-tool-versions/action.yaml
junhaoliao
left a comment
There was a problem hiding this comment.
i have no further concerns other than the ones @davidlion has brought up. if i understand correctly, we will create follow up PRs to address those. then I think we can merge this PR first to quickly unblock the other PRs across different repos that address potential security risks in the CI pipelines
Let's wait for @davidlion 's confirmation before merging
Description
Adds reusable composite actions for shared CI tool setup and updates this repo’s workflows to use them as well.
npm install -g @go-task/cliwithgo-task/setup-taskaction to eliminate npm supply-chain risk. #109 indirectly, which should be closed by the merge of this PR.Checklist
breaking change.
Validation performed
actions/checkoutto v6.0.2; Fix task paths intaskfiles/docs.yaml. spider#298Summary by CodeRabbit
New Features
Chores