chore: Create CI Workflow Build DAWGS PKGs#81
Conversation
Resolves: PQE-406
WalkthroughA GitHub Actions workflow is added to build the DAWGS packages on pull requests targeting main and stage/* branches. The workflow provisions a Linux runner, installs Go from go.mod with caching, and runs ChangesCI Build Workflow
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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/build.yml:
- Around line 24-26: The pull_request trigger only lists "opened" and
"synchronize" under the types array, so update the types list to include
"reopened" (i.e., add the "reopened" entry alongside "opened" and "synchronize")
so the workflow runs when a PR is reopened; modify the types block that
currently contains "opened" and "synchronize" to include "reopened".
- Around line 33-37: The workflow currently uses mutable tags
"actions/checkout@v4" and "actions/setup-go@v5"; replace those uses lines with
the corresponding full commit SHAs for actions/checkout and actions/setup-go
(keeping the human-readable tag as a trailing comment if desired) so the
workflow is pinned to immutable commits, and consider enabling
Dependabot/Renovate to keep the SHAs up-to-date; update the two occurrences
referencing actions/checkout and actions/setup-go accordingly.
🪄 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: CHILL
Plan: Pro
Run ID: 1cfb9fdc-a7c0-4d6e-ab54-641df8a4e359
📒 Files selected for processing (1)
.github/workflows/build.yml
| types: | ||
| - "opened" | ||
| - "synchronize" |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
In GitHub Actions pull_request triggers, what events are included by default, and what is the effect of specifying only types: [opened, synchronize] on reopened PRs?
💡 Result:
In GitHub Actions, the pull_request event includes several activity types by default. If you do not specify any types, the workflow will automatically trigger when a pull request is opened, synchronized (when new commits are pushed to the head branch), or reopened [1][2][3]. When you explicitly define the types keyword in your workflow configuration, you override these defaults entirely [3]. If you specify only types: [opened, synchronize], the workflow will no longer trigger on the reopened activity type [1][2][3]. Consequently, if a pull request is closed and subsequently reopened, any workflow configured with only these two types will not execute for that specific event [1][2][3]. To include reopened pull requests, you must explicitly add reopened to your list of types [3].
Citations:
- 1: https://docs.github.com/actions/reference/workflows-and-actions/events-that-trigger-workflows
- 2: https://docs.github.com/actions/using-workflows/events-that-trigger-workflows
- 3: https://frontside.com/blog/2020-05-26-github-actions-pull_request/
Add reopened to PR trigger types to ensure CI runs on reopened pull requests.
At Lines 24–26, the current configuration limits triggers to opened and synchronize. This overrides GitHub's defaults and excludes the reopened activity type. When a PR is closed and reopened without new commits, the workflow will not execute. Add reopened to the types list to re-run CI on this common PR lifecycle event.
types:
- "opened"
- "reopened"
- "synchronize"
🤖 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/build.yml around lines 24 - 26, The pull_request trigger
only lists "opened" and "synchronize" under the types array, so update the types
list to include "reopened" (i.e., add the "reopened" entry alongside "opened"
and "synchronize") so the workflow runs when a PR is reopened; modify the types
block that currently contains "opened" and "synchronize" to include "reopened".
| uses: actions/checkout@v4 | ||
|
|
||
| - name: Install Go | ||
| uses: actions/setup-go@v5 | ||
| with: |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What is GitHub’s current security guidance on pinning GitHub Actions to immutable commit SHAs versus version tags like @v4?
💡 Result:
GitHub's official security guidance explicitly recommends pinning GitHub Actions to a full-length commit SHA as the only way to use an action as an immutable release [1][2][3]. Key aspects of this guidance include: Immutable Security: Pinning to a full-length commit SHA mitigates the risk of supply chain attacks where a bad actor might compromise an action's repository and modify or delete existing version tags (e.g., @v4) to point to malicious code [4][1][2]. Avoid Short SHAs: GitHub warns that short commit SHAs are insecure and should never be used, as they are susceptible to collision attacks where a malicious actor could push a crafted commit to a fork that matches the short SHA [2]. Tag Usage: While pinning to a tag (e.g., @v4) is more convenient and widely used, GitHub advises that this should only be done if you fully trust the action's creator [1][2]. Even with trusted authors, tags remain mutable and carry inherent risks [1][3]. Organizational Control: GitHub provides features that allow organizations and repositories to enforce security policies, including the ability to mandate that all actions be pinned to a full-length commit SHA [5][1][3]. To maintain security while using SHAs, it is common practice to include the version tag as a comment in the workflow file for readability and easier maintenance (e.g., uses: actions/checkout@93cb6ef # v5) [6][5][7]. Automated tools like Dependabot or Renovate are frequently recommended to help manage and update these pinned SHAs [6][4].
Citations:
- 1: https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions?learn=getting_started&learnProduct=actions
- 2: https://docs.github.com/enterprise-server@3.0/actions/security-guides/security-hardening-for-github-actions
- 3: https://docs.github.com/en/actions/reference/security/secure-use
- 4: Pin GitHub Actions to commit SHAs instead of version tags ankitects/anki#4722
- 5: https://dev.to/ciberconscientes/github-actions-why-you-should-pin-your-actions-to-a-specific-version-1513
- 6: Pin all GitHub Actions to immutable SHA commits for supply chain security github/gh-aw#5691
- 7: https://github.com/step-security/github-actions-goat/blob/main/docs/Solutions/PinGitHubActions.md
🏁 Script executed:
cat -n .github/workflows/build.yml | head -50Repository: SpecterOps/DAWGS
Length of output: 1487
Pin GitHub Actions to commit SHAs for supply-chain hardening.
At lines 33 and 36, actions/checkout@v4 and actions/setup-go@v5 use mutable version tags. GitHub's security guidance recommends pinning to full-length commit SHAs to mitigate supply-chain attack risks. Optionally include the version tag as a comment for readability:
Suggested change
- name: Checkout source code for this repository
- uses: actions/checkout@v4
+ uses: actions/checkout@<full_commit_sha> # v4
- name: Install Go
- uses: actions/setup-go@v5
+ uses: actions/setup-go@<full_commit_sha> # v5Consider using Dependabot or Renovate to automate SHA pinning and updates.
🤖 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/build.yml around lines 33 - 37, The workflow currently
uses mutable tags "actions/checkout@v4" and "actions/setup-go@v5"; replace those
uses lines with the corresponding full commit SHAs for actions/checkout and
actions/setup-go (keeping the human-readable tag as a trailing comment if
desired) so the workflow is pinned to immutable commits, and consider enabling
Dependabot/Renovate to keep the SHAs up-to-date; update the two occurrences
referencing actions/checkout and actions/setup-go accordingly.
There was a problem hiding this comment.
Let's pin the SHA! @ykaiboussiSO would you mind also pinning the SHA for the other actions in this repo please 🙏
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
2 participants
Description
Create basic CI Workflow Build DAWGS
Resolves: PQE-406
Type of Change
Testing
make test_allwithCONNECTION_STRINGset)Screenshots (if appropriate):
Driver Impact
drivers/pg)drivers/neo4j)Checklist
go.mod/go.sumare up to date if dependencies changedSummary by CodeRabbit