Add CI/CD pipeline and package managers support#15
Conversation
- Added a `Makefile` for robust compilation (`make`, `make test`, `make install`) - Added `.github/workflows/ci.yml` for testing on main branches - Added `.github/workflows/release.yml` for automated releases and artifact builds - Added `flake.nix` for Nix/NixOS reproducible builds and deployment - Added `HomebrewFormula/ado.rb` to support homebrew installation, automated by CD - Updated `make install` to alias `doc` binary to `ado` to follow standards
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThis PR introduces complete build infrastructure for the ado project: a Makefile providing core build, test, and install targets; a Nix flake for development; a CI workflow for continuous testing; a multi-stage release workflow that builds artifacts, publishes releases, and updates the Homebrew formula; and the Homebrew formula template itself. ChangesBuild Infrastructure and Release Automation
Estimated Code Review Effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 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 |
![amazon-q-developer[bot]](https://avatars.githubusercontent.com/in/1220912?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary
This PR adds CI/CD pipeline and package manager support. The implementation has 4 critical issues that must be fixed before merge:
Critical Issues Found:
- release.yml (line 29) - Artifacts use wrong binary reference
- HomebrewFormula/ado.rb (lines 3-5) - Placeholder values will cause installation failures
- HomebrewFormula/ado.rb (line 10) - Binary installation reference issue
- release.yml (line 91) - Missing error handling for git commit failures
Overall Assessment:
The CI/CD structure is sound, but the issues above will prevent successful releases and package installations. All critical issues have been marked with detailed comments.
You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.
|
|
||
| def install | ||
| system "make" | ||
| bin.install "doc" => "ado" |
There was a problem hiding this comment.
🛑 Logic Error: Installs wrong binary. The Makefile compiles to doc executable which should be installed as ado.
bin.install "doc" => "ado"| - name: Prepare Artifact | ||
| run: | | ||
| mkdir -p dist | ||
| cp doc dist/${{ matrix.artifact_name }} |
There was a problem hiding this comment.
🛑 Logic Error: Replace doc with the actual compiled binary name that matches the Makefile output. The Makefile target is named doc but should be the executable binary.
cp doc dist/${{ matrix.artifact_name }}![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces build and distribution configurations for the Ado programming language, including a Homebrew formula, a Makefile, and a Nix flake. Feedback was provided to replace placeholders in the Homebrew formula with valid project URLs and checksums. In the Makefile, it is recommended to use object files for incremental compilation and to remove redundant compilation steps from the test script. Additionally, the Nix flake configuration should be cleaned up by removing the redundant GCC dependency from the standard environment.
| homepage "https://github.com/OWNER/REPO" | ||
| url "https://github.com/OWNER/REPO/archive/refs/tags/v0.1.0.tar.gz" | ||
| sha256 "REPLACE_WITH_SHA256" |
There was a problem hiding this comment.
The homepage, url, and sha256 fields contain placeholders (OWNER/REPO, REPLACE_WITH_SHA256). These must be updated to valid values for the formula to be functional. While the PR description mentions automation for the SHA, the repository path placeholders still need to be resolved to point to the actual project location.
| doc: $(SRCS) | ||
| $(CC) $(CFLAGS) -o $@ $(SRCS) $(LDFLAGS) |
There was a problem hiding this comment.
The current rule recompiles all source files every time the doc target is built. It is more efficient to use the OBJS variable (defined on line 9) to leverage incremental compilation. This allows make to only recompile files that have changed, significantly speeding up the build process during development.
doc: $(OBJS)
$(CC) $(CFLAGS) -o $@ $(OBJS) $(LDFLAGS)
| $(CC) $(CFLAGS) -o $@ $(TEST_SRCS) $(LDFLAGS) | ||
|
|
||
| test: doc test_main | ||
| ./test.sh |
There was a problem hiding this comment.
The test.sh script (referenced here) contains a hardcoded compilation command (cc -o test_main ... on line 14) which bypasses the Makefile configuration and performs redundant work. Since test_main is already a dependency of the test target in this Makefile, you should consider removing the compilation step from test.sh and having it only execute the test binaries. This ensures that build flags like CFLAGS are respected consistently.
| version = "unstable"; | ||
| src = ./.; | ||
|
|
||
| buildInputs = [ pkgs.gcc ]; |
There was a problem hiding this comment.
Explicitly adding pkgs.gcc to buildInputs is redundant when using pkgs.stdenv.mkDerivation, as a C compiler is already provided by the standard environment. If a specific compiler version or a different compiler (like Clang) is required, it should typically be placed in nativeBuildInputs.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 339ff7b51c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| end | ||
|
|
||
| test do | ||
| (testpath/"test.do").write("print(\"hello from ado\")\n") |
There was a problem hiding this comment.
The formula test writes print("hello from ado") as a top-level statement, but this compiler only emits output when code is inside fn main() { ... }; running the installed binary with the current test input produces no hello from ado output, so assert_match fails and the formula cannot pass brew test/test-bot. Update the test program to include a main function so the package verification actually exercises a runnable Ado program.
Useful? React with 👍 / 👎.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (1)
HomebrewFormula/ado.rb (1)
8-10: ⚡ Quick winPrefer
make installfrom the formula to stay aligned with Makefile install logic.This avoids duplicating binary mapping behavior in two places.
Suggested patch
def install - system "make" - bin.install "doc" => "ado" + system "make", "install", "PREFIX=#{prefix}" end🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@HomebrewFormula/ado.rb` around lines 8 - 10, In the install method, replace the current two-step build+manual install (system "make" and bin.install "doc" => "ado") with invoking the Makefile's install target so the formula follows the package's own install logic; update the install method to call the Makefile install (i.e., run the appropriate system "make install" instead of system "make" and remove the bin.install "doc" => "ado" mapping) so the package's intended installation paths and steps are preserved.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/ci.yml:
- Line 17: The workflow uses mutable refs for actions (actions/checkout@v4 and
DeterminateSystems/nix-installer-action@main); replace those mutable tags with
their corresponding full-length commit SHAs in the .github/workflows/ci.yml file
so the steps refer to immutable commits instead of moving tags/branches—locate
the uses of actions/checkout and DeterminateSystems/nix-installer-action in the
workflow and update their ref to the full commit SHA for the exact release you
want to pin.
- Around line 3-7: Update the workflow to follow least-privilege: add a
top-level permissions map giving only required read access (for example
permissions: contents: read) and, in the checkout step (actions/checkout) set
persist-credentials: false to prevent persisting GITHUB_TOKEN in the working
copy; ensure both changes are added to the workflow YAML so the file uses
minimal permissions and disables persisted checkout credentials.
In @.github/workflows/release.yml:
- Around line 91-92: Make the Homebrew formula commit step idempotent by
detecting whether there are staged changes before running the commit command;
replace the unconditional git commit invocation (the step that runs git commit
-m "Update Homebrew formula for ${TAG_NAME}") with logic that only performs the
commit when there is an actual diff staged, otherwise skip the commit and
continue to the existing git push origin main step so re-runs don't fail when no
formula changes exist.
- Line 21: Replace loose version tags with pinned commit SHAs and upgrade the
deprecated GitHub Release action: update uses: actions/checkout@v4 to a full
commit SHA for actions/checkout, replace softprops/action-gh-release@v1 with the
v3-compatible release action (and pin it to its specific commit SHA), and
similarly pin any other actions referenced (e.g., upload-release-asset or
github-script usages at the other mentioned spots) to their full commit SHAs;
ensure you update the uses: entries for the symbols actions/checkout and
softprops/action-gh-release (and any other action names referenced in the file)
to the appropriate SHA-based refs so the workflow runs on modern runners and is
reproducible.
In `@HomebrewFormula/ado.rb`:
- Around line 3-5: The formula metadata in HomebrewFormula/ado.rb contains
placeholders: update the homepage, url, and sha256 fields (the lines setting
homepage, url, and sha256) to the actual repository owner/name and the correct
release tarball SHA256; specifically replace "https://github.com/OWNER/REPO" and
"https://github.com/OWNER/REPO/archive/refs/tags/v0.1.0.tar.gz" with the real
repo URL and release tarball URL, and replace "REPLACE_WITH_SHA256" with the
computed SHA256 of that tarball so the formula can be installed.
---
Nitpick comments:
In `@HomebrewFormula/ado.rb`:
- Around line 8-10: In the install method, replace the current two-step
build+manual install (system "make" and bin.install "doc" => "ado") with
invoking the Makefile's install target so the formula follows the package's own
install logic; update the install method to call the Makefile install (i.e., run
the appropriate system "make install" instead of system "make" and remove the
bin.install "doc" => "ado" mapping) so the package's intended installation paths
and steps are preserved.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: aec3bea8-c927-47b2-b27d-cf2723488123
📒 Files selected for processing (6)
.github/workflows/ci.yml.github/workflows/release.ymlHomebrewFormula/ado.rbMakefiledocflake.nix
| on: | ||
| push: | ||
| branches: [ "main" ] | ||
| pull_request: | ||
| branches: [ "main" ] |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat .github/workflows/ci.ymlRepository: clpi/dopl
Length of output: 594
🌐 Web query:
GitHub Actions checkout action security best practices 2024 2025
💡 Result:
Security best practices for GitHub Actions that use actions/checkout (2024–2025), grounded in official/authoritative guidance: 1) Least-privilege GITHUB_TOKEN permissions (default to read) Set workflow/job-level permissions so GITHUB_TOKEN has only what you need (good practice: default contents: read, increase per job when required). [1][2] Example: permissions: contents: read 2) Use actions/checkout with persist-credentials: false when you don’t need authenticated git If you don’t require git authentication for later steps, disable credential persistence so the token/PAT is not configured in the runner’s local git config. The checkout action documents this option. [3][4] Example: - uses: actions/checkout@v4 with: persist-credentials: false 3) Prefer immutable refs (commit SHA) over mutable refs (branches/PR numbers) Avoid checking out code using mutable references; instead check out a specific commit SHA. This reduces the risk of race/target changes between workflow creation and execution. [3] 4) Do not run untrusted PR code in privileged contexts (especially pull_request_target) OWASP’s GitHub Actions security guidance explicitly warns: never check out (via actions/checkout or GitHub CLI) and run untrusted code in pull_request_target-like contexts. Use safer patterns that avoid executing untrusted code with write-capable tokens/secrets. [3] 5) Pin and review action usage; prefer GitHub-owned actions when possible Security guidance recommends reducing supply-chain risk by checking actions for known vulnerabilities and prioritizing GitHub-owned actions where possible. [5] 6) Avoid broad token scope during untrusted-code runs (reduce blast radius) When workflows run on untrusted code (e.g., external PRs), restrict permissions (read-only) or split into privileged vs non-privileged workflows and share data via artifacts. [5] 7) Audit secrets handling and workflow logs GitHub’s hardening guidance recommends auditing how secrets are used (not sent to unintended hosts, not printed), and reviewing workflow logs to ensure secrets are properly redacted. [1] 8) When using actions/checkout’s auth inputs (token/ssh-key), use least-privilege credentials The checkout action docs recommend using a service account/PAT with least necessary permissions and limited scopes. [6][7] Practical hardened checkout template - uses: actions/checkout@v4 with: ref: ${{ github.sha }} persist-credentials: false (Then pair it with workflow permissions like permissions: { contents: read } unless a later job truly needs more.) [3][1][4] If you share your workflow trigger (push vs pull_request vs pull_request_target) and whether you need to push back to the repo (authenticated git operations), I can tailor the exact recommended permissions and checkout settings.
Citations:
- 1: https://docs.github.com/actions/learn-github-actions/security-hardening-for-github-actions
- 2: https://docs.github.com/en/actions/reference/security/secure-use
- 3: https://cheatsheetseries.owasp.org/cheatsheets/GitHub_Actions_Security_Cheat_Sheet.html
- 4: https://github.com/actions/checkout/blob/v4/README.md
- 5: https://openssf.org/blog/2024/08/12/mitigating-attack-vectors-in-github-workflows/
- 6: https://github.com/actions/checkout
- 7: https://github.com/actions/checkout/blob/v4/action.yml
Set least-privilege permissions and disable persisted checkout credentials.
This workflow only needs read access; persisting credentials in the working copy is unnecessary here.
Suggested patch
name: CI
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
+permissions:
+ contents: read
+
jobs:
build-and-test:
@@
- - uses: actions/checkout@v4
+ - uses: actions/checkout@v4
+ with:
+ persist-credentials: false🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ci.yml around lines 3 - 7, Update the workflow to follow
least-privilege: add a top-level permissions map giving only required read
access (for example permissions: contents: read) and, in the checkout step
(actions/checkout) set persist-credentials: false to prevent persisting
GITHUB_TOKEN in the working copy; ensure both changes are added to the workflow
YAML so the file uses minimal permissions and disables persisted checkout
credentials.
| os: [ubuntu-latest, macos-latest] | ||
|
|
||
| steps: | ||
| - uses: actions/checkout@v4 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cd /repo && find . -name "ci.yml" -type f | head -20Repository: clpi/dopl
Length of output: 109
🏁 Script executed:
cat -n .github/workflows/ci.yml | head -40Repository: clpi/dopl
Length of output: 811
🌐 Web query:
GitHub Actions pinning best practices security commit SHA vs tag
💡 Result:
Best practice: pin GitHub Actions “uses:” references to the full-length immutable commit SHA, not a tag, to reduce supply-chain risk. Why SHA (not tags) for security - GitHub states that “Pinning an action to a full-length commit SHA is currently the only way to use an action as an immutable release,” and it helps mitigate risk from backdoors because the attacker would need to generate a SHA-1 collision for a valid Git object payload. [1] - GitHub also notes that pinning to a tag is risky even if you trust the creator because “a tag can be moved or deleted if a bad actor gains access” to the repository. [1] When/if you must use tags - GitHub says pinning to a tag is more convenient and widely used, but you should only do it if you trust the action’s creators (e.g., the “Verified creator” badge as a signal), and understand the tag-move/delete risk remains. [1] Recommended workflow pattern - Use: owner/repo@ in your workflow YAML (optionally with a comment indicating which released version the SHA corresponds to). For example, GitHub’s own security guidance emphasizes full-length SHAs as the immutable option. [1] Operationally enforcing SHA pinning - GitHub provides an Actions policy (“allowed actions policy”) that can enforce SHA pinning; workflows that try to use an action that isn’t pinned to a full commit SHA can be made to fail. [2] Bottom line - For maximum security against supply-chain attacks or tag manipulation, pin to a full-length commit SHA. [1] - Optionally enforce this at the org/repo level with GitHub’s SHA pinning policy so unpinned tag references don’t slip in. [2]
Citations:
- 1: https://docs.github.com/en/actions/reference/security/secure-use
- 2: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
Pin workflow actions to immutable commit SHAs.
actions/checkout@v4 and DeterminateSystems/nix-installer-action@main use mutable references (moving tag and branch). GitHub's security guidance recommends pinning to full-length commit SHAs to prevent supply-chain attacks, as tags and branches can be moved or deleted if an account is compromised.
Suggested patch
- - uses: actions/checkout@v4
+ - uses: actions/checkout@<checkout-commit-sha>
- name: Check Nix flake
if: runner.os == 'Linux'
- uses: DeterminateSystems/nix-installer-action@main
+ uses: DeterminateSystems/nix-installer-action@<nix-installer-commit-sha>🧰 Tools
🪛 zizmor (1.25.2)
[warning] 17-17: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 17-17: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ci.yml at line 17, The workflow uses mutable refs for
actions (actions/checkout@v4 and DeterminateSystems/nix-installer-action@main);
replace those mutable tags with their corresponding full-length commit SHAs in
the .github/workflows/ci.yml file so the steps refer to immutable commits
instead of moving tags/branches—locate the uses of actions/checkout and
DeterminateSystems/nix-installer-action in the workflow and update their ref to
the full commit SHA for the exact release you want to pin.
| artifact_name: ado-macos-arm64 | ||
|
|
||
| steps: | ||
| - uses: actions/checkout@v4 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "release.yml" -type fRepository: clpi/dopl
Length of output: 85
🏁 Script executed:
cat -n .github/workflows/release.ymlRepository: clpi/dopl
Length of output: 3069
🌐 Web query:
softprops/action-gh-release v1 v2 github actions compatibility
💡 Result:
softprops/action-gh-release v1 and v2 compatibility (as of today, 2026-05-19) Answer: You can generally move from v1 to v2 by keeping the same workflow inputs/usage pattern (uses: softprops/action-gh-release@v1/v2). The main compatibility break people hit is not the YAML inputs, but runtime/platform expectations: v3 introduces a Node 24 requirement (so if you still need Node 20 compatibility, stay on the last Node-20-compatible v2 line, v2.6.2). [1] What this means for v1 vs v2 specifically - Both v1 and v2 are “the same action” from the same repository and are used the same way in workflows (uses: softprops/action-gh-release@v1 or @v2, with inputs under with:). The action’s own repo documentation shows the current usage for v2/v3 and explains the runtime boundary for v3; by implication, v2 remains the compatible line if you can’t meet v3’s Node requirement. [1] Key compatibility guidance (most important) - If you are considering upgrading to v3: v3 requires a GitHub Actions runtime that supports Node 24; if you still need the last Node 20-compatible line, stay on v2.6.2. [1] So, for “v1 v2 compatibility”, the practical recommendation - Upgrade v1 -> v2 if you’re not hitting any input-level changes in your workflow; usage remains the same. [1] - If your environment requires Node 20 compatibility (common reason to avoid newer major versions), use v2.6.2 (and don’t jump to v3). [1] If you share your current workflow snippet (especially the uses: line and any with: inputs), I can tell you whether any specific input you use is known to have changed across v1->v2 for your exact case.
Citations:
🌐 Web query:
softprops/action-gh-release@v1 deprecated EOL unsupported 2025 2026
💡 Result:
The softprops/action-gh-release@v1 version is not explicitly marked as "EOL" or "unsupported" by a single official deprecation notice, but it is effectively obsolete due to the evolution of GitHub Actions runner requirements [1][2]. Key context regarding its status: 1. Runtime Incompatibility: GitHub Actions runners have transitioned away from older Node.js versions [3][4]. Specifically, Node.js 20 reached end-of-life (EOL) on April 30, 2026, and GitHub is actively removing it from runner images in favor of newer versions like Node.js 22 and Node.js 24 [4][5]. Because v1 of this action was built for older Node.js environments, it may fail or behave unpredictably on modern runners [1][2]. 2. Recommended Migration: The maintainer has released v3, which is explicitly designed for the Node.js 24 runtime [1][2]. Users still requiring a Node.js 20-compatible version are advised to use v2.6.2 [1][2]. Version 1 is significantly outdated and lacks support for these newer, required runtime environments [1][2]. 3. General Best Practice: It is standard practice in the GitHub Actions ecosystem to update to the latest major version (currently v3) to ensure compatibility with updated runner images and security standards [1][2][3]. In summary, while v1 may technically still execute in some legacy configurations, it is unsupported for modern GitHub Actions environments and should be upgraded to v3 [1][2].
Citations:
- 1: https://github.com/softprops/action-gh-release
- 2: softprops/action-gh-release@a06a81a...b430933
- 3: https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
- 4: [All OS] Default Node.js version will be changed from 20 to 22 and Node.js 20 will be removed from runner images actions/runner-images#14029
- 5: ubuntu-latest default Node.js 20.20.2 unsupported actions/runner-images#13833
🌐 Web query:
GitHub Actions best practices pinning commit SHA vs version tags 2025 2026
💡 Result:
Best practice (2025–2026): pin GitHub Actions to a full-length commit SHA, not to a version tag, unless you explicitly trust the tag maintainer. Why pin to full commit SHA (vs tags) 1) Full SHA pinning is the only way to treat an action as an “immutable release.” GitHub’s secure use guidance states that pinning an action to a full-length commit SHA is currently the only way to use an action as an immutable release.[1] 2) Tags are mutable and therefore not an immutable reference. GitHub’s guidance notes that even if you trust the creator, a tag can be moved or deleted if a bad actor gains access to the repository that stores the action.[1][2] 3) SHAs mitigate backdoor/supply-chain risk because the attacker would need to generate a SHA-1 collision for a valid Git object payload (GitHub’s explanation of the mitigation).[1] What “best practice” looks like in workflows - Prefer a full-length SHA in your uses: reference (and avoid abbreviated SHAs). GitHub’s security hardening guide warns that the short version of the commit SHA is insecure and should never be used for specifying an action’s Git reference.[3] - Optionally add a comment with the human version you validated (so you can track intent while still executing by SHA). (Community guidance commonly recommends this pattern; GitHub’s docs focus on the SHA requirement.)[4] When tags are acceptable - GitHub says: pin to a tag only if you trust the creator (but it still carries risk because tags can be moved or deleted).[1][2] - Practically, teams often use tags for “convenience,” but move to SHA pinning for higher assurance and in environments with centralized policy enforcement.[5] Policy enforcement (why this became more “must-do” in 2025/2026) - GitHub introduced organization/repository-level policies to require actions to be pinned to a full-length commit SHA; workflows referencing tags (or other mutable references) will fail when the policy is enabled.[1] Notes about automated updates (Dependabot) - GitHub’s docs note that Dependabot only creates alerts for vulnerable actions that use semantic versioning, and will not create alerts for actions pinned to SHA values.[1] - So SHA pinning improves immutability, but you may need an additional process (e.g., separate vulnerability scanning) beyond Dependabot alerts if you rely on Dependabot for security reporting.[1] Bottom line - For secure, reproducible GitHub Actions in 2025–2026: pin to full-length commit SHAs (preferably with a human-readable version comment) and avoid tags/branches like v4, main, or latest unless you explicitly trust the tag publisher and accept mutability risk.[1][3] Example - Good (full-length SHA): uses: actions/checkout@a824008085750b8e136effc585c3cd6082bd575f.[6] - Avoid (tag): uses: actions/checkout@v4 / @main / @latest (mutable references).[1][2]
Citations:
- 1: https://docs.github.com/en/actions/reference/security/secure-use
- 2: https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions?learn=getting_started&learnProduct=actions
- 3: https://docs.github.com/enterprise-server@3.0/actions/security-guides/security-hardening-for-github-actions
- 4: https://dev.to/ciberconscientes/github-actions-why-you-should-pin-your-actions-to-a-specific-version-1513
- 5: https://www.wiz.io/blog/github-actions-security-guide
- 6: https://docs.github.com/en/actions/how-tos/creating-and-publishing-actions/managing-custom-actions
Upgrade and pin release actions; softprops/action-gh-release@v1 is incompatible with current GitHub Actions runners.
Version 1 was built for older Node.js versions and will fail on modern runners that require Node 24. Upgrade to v3 (currently recommended) and pin all actions to full-length commit SHAs for security and reproducibility, not version tags.
Suggested patch
- - uses: actions/checkout@v4
+ - uses: actions/checkout@a824008085750b8e136effc585c3cd6082bd575f
@@
- - name: Upload Artifact
- uses: actions/upload-artifact@v4
+ - name: Upload Artifact
+ uses: actions/upload-artifact@65462800fd760344d8b9c0e56cf798bf5dfedf11
@@
- - uses: actions/checkout@v4
+ - uses: actions/checkout@a824008085750b8e136effc585c3cd6082bd575f
@@
- - name: Download Artifacts
- uses: actions/download-artifact@v4
+ - name: Download Artifacts
+ uses: actions/download-artifact@65a9edc5148cb203b7649a1d7410e69cd6029bab
@@
- - name: Create Release
- uses: softprops/action-gh-release@v1
+ - name: Create Release
+ uses: softprops/action-gh-release@v3
@@
- - uses: actions/checkout@v4
+ - uses: actions/checkout@a824008085750b8e136effc585c3cd6082bd575fAlso applies to: 32-32, 45-45, 48-48, 53-53, 68-68
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 21-21: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 21-21: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/release.yml at line 21, Replace loose version tags with
pinned commit SHAs and upgrade the deprecated GitHub Release action: update
uses: actions/checkout@v4 to a full commit SHA for actions/checkout, replace
softprops/action-gh-release@v1 with the v3-compatible release action (and pin it
to its specific commit SHA), and similarly pin any other actions referenced
(e.g., upload-release-asset or github-script usages at the other mentioned
spots) to their full commit SHAs; ensure you update the uses: entries for the
symbols actions/checkout and softprops/action-gh-release (and any other action
names referenced in the file) to the appropriate SHA-based refs so the workflow
runs on modern runners and is reproducible.
| homepage "https://github.com/OWNER/REPO" | ||
| url "https://github.com/OWNER/REPO/archive/refs/tags/v0.1.0.tar.gz" | ||
| sha256 "REPLACE_WITH_SHA256" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "ado.rb" -type f | grep -i homebrewRepository: clpi/dopl
Length of output: 78
🏁 Script executed:
cat -n HomebrewFormula/ado.rb | head -10Repository: clpi/dopl
Length of output: 413
Replace placeholder formula metadata before merge.
Placeholder values (OWNER/REPO and REPLACE_WITH_SHA256) prevent the formula from being installable. Update with actual repository details and correct SHA256 hash.
Suggested patch
- homepage "https://github.com/OWNER/REPO"
- url "https://github.com/OWNER/REPO/archive/refs/tags/v0.1.0.tar.gz"
- sha256 "REPLACE_WITH_SHA256"
+ homepage "https://github.com/clpi/dopl"
+ url "https://github.com/clpi/dopl/archive/refs/tags/v0.1.0.tar.gz"
+ sha256 "<real-source-tarball-sha256>"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| homepage "https://github.com/OWNER/REPO" | |
| url "https://github.com/OWNER/REPO/archive/refs/tags/v0.1.0.tar.gz" | |
| sha256 "REPLACE_WITH_SHA256" | |
| homepage "https://github.com/clpi/dopl" | |
| url "https://github.com/clpi/dopl/archive/refs/tags/v0.1.0.tar.gz" | |
| sha256 "<real-source-tarball-sha256>" |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@HomebrewFormula/ado.rb` around lines 3 - 5, The formula metadata in
HomebrewFormula/ado.rb contains placeholders: update the homepage, url, and
sha256 fields (the lines setting homepage, url, and sha256) to the actual
repository owner/name and the correct release tarball SHA256; specifically
replace "https://github.com/OWNER/REPO" and
"https://github.com/OWNER/REPO/archive/refs/tags/v0.1.0.tar.gz" with the real
repo URL and release tarball URL, and replace "REPLACE_WITH_SHA256" with the
computed SHA256 of that tarball so the formula can be installed.
There was a problem hiding this comment.
Pull request overview
This PR adds first-class build automation and packaging support for the Ado compiler repository by introducing a Makefile-based build/test/install interface, Nix flake packaging, and GitHub Actions workflows for CI and tagged releases (including automated Homebrew formula updates).
Changes:
- Added a
Makefilewithall,test,install, anduninstalltargets. - Added a Nix flake (
flake.nix) providing a build derivation and a dev shell. - Added GitHub Actions CI (
ci.yml) and release automation (release.yml), plus a Homebrew formula template.
Reviewed changes
Copilot reviewed 5 out of 6 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
| Makefile | Adds standard build/test/install targets for local builds and packaging. |
| HomebrewFormula/ado.rb | Introduces a Homebrew formula (currently with placeholder metadata) for packaging. |
| flake.nix | Adds Nix flake packaging and dev shell for reproducible builds. |
| .github/workflows/ci.yml | Adds CI on Ubuntu/macOS and runs nix flake check on Linux. |
| .github/workflows/release.yml | Automates tagged release artifacts and updates the Homebrew formula on main. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| install -m 755 doc $(DESTDIR)$(BINDIR)/ado | ||
|
|
||
| uninstall: | ||
| rm -f $(DESTDIR)$(BINDIR)/ado |
| test: doc test_main | ||
| ./test.sh |
| class Ado < Formula | ||
| desc "Ado - A Minimal Programming Language" | ||
| homepage "https://github.com/OWNER/REPO" | ||
| url "https://github.com/OWNER/REPO/archive/refs/tags/v0.1.0.tar.gz" | ||
| sha256 "REPLACE_WITH_SHA256" | ||
| license "MIT" | ||
|
|
||
| def install | ||
| system "make" | ||
| bin.install "doc" => "ado" | ||
| end | ||
|
|
||
| test do | ||
| (testpath/"test.do").write("print(\"hello from ado\")\n") | ||
| assert_match "hello from ado", shell_output("#{bin}/ado test.do") | ||
| end | ||
| end |
| system "make" | ||
| bin.install "doc" => "ado" |
| ado = pkgs.stdenv.mkDerivation { | ||
| pname = "ado"; | ||
| version = "unstable"; | ||
| src = ./.; | ||
|
|
||
| buildInputs = [ pkgs.gcc ]; | ||
|
|
||
| makeFlags = [ "PREFIX=$(out)" ]; | ||
|
|
||
| doCheck = true; | ||
| checkTarget = "test"; | ||
| }; |
|
|
||
| - name: Check Nix flake | ||
| if: runner.os == 'Linux' | ||
| uses: DeterminateSystems/nix-installer-action@main |
| # Commit and push | ||
| git config user.name "github-actions[bot]" | ||
| git config user.email "github-actions[bot]@users.noreply.github.com" | ||
| git add HomebrewFormula/ado.rb | ||
| git commit -m "Update Homebrew formula for ${TAG_NAME}" | ||
| git push origin main |
Co-authored-by: amazon-q-developer[bot] <208079219+amazon-q-developer[bot]@users.noreply.github.com>
Co-authored-by: amazon-q-developer[bot] <208079219+amazon-q-developer[bot]@users.noreply.github.com>
Implemented a robust CI/CD pipeline and added package manager support for Nix and Homebrew as requested.
The changes involve:
Makefilethat compiles the C project and allows easy packaging by building and testing standard targets (all,test,install).flake.nixfile that implements a default build derivation and a developer shell for local development via Nix.ci.ymlwhich tests pushes and PRs on Ubuntu and macOS, including running a nix flake check.release.ymlwhich, on tag pushes (v*), builds release artifacts for multiple architectures, uploads them as GitHub Releases, and automates calculating the SHA256 sum of the source tarball and pushing the updated version back toHomebrewFormula/ado.rbon themainbranch.PR created automatically by Jules for task 9739680542015567981 started by @clpi
Summary by CodeRabbit
New Features
Chores