Update config.yml #75
Conversation
|
Yooo! You forgot to bump the version in package.json! |
WalkthroughThis PR updates the CircleCI configuration to fix a typo in the build job name, enhance Slack notification formatting for E2E test results, and introduce two new publishing jobs (npm package and GitHub release) with updated workflow orchestration and branch filtering. Changes
Sequence DiagramsequenceDiagram
autonumber
participant CI as CircleCI Pipeline
participant Install as install
participant E2E as e2e-tests
participant Publish as publish-npm-package
participant Release as publish-github-release
CI->>Install: Run on master branch
Install-->>E2E: Trigger after install
E2E->>E2E: Run E2E tests<br/>(with enhanced notifications)
E2E-->>Publish: Trigger on success
Publish->>Publish: Authenticate to npm<br/>Publish package<br/>Announce completion
Publish-->>Release: Trigger after publish
Release->>Release: Create GitHub release<br/>via ghr
Release-->>CI: Workflow complete
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes The single-file configuration change involves coordinated updates to job definitions, workflow dependencies, and branch filtering logic. While formatting and naming fixes are straightforward, the new npm and GitHub release jobs require careful verification of authentication setup, publish steps, and workflow dependency chains. Possibly related PRs
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.circleci/config.yml (1)
167-215: Consider adding error handling and notifications to publish jobs.The new
publish-npm-packageandpublish-github-releasejobs lack error handling or post-publish notifications. Consider:
- Add
when: on_successorwhen: on_failguards if you want these jobs to fail gracefully or retry under certain conditions.- Add a notification step (Slack, email, etc.) after successful publish to confirm the release is live.
- Ensure that if
publish-npm-packagefails,publish-github-releasedoes not proceed (therequiresdependency should handle this, but log the failure clearly).This will improve observability and catch publishing failures early.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.circleci/config.yml(5 hunks)
🔇 Additional comments (4)
.circleci/config.yml (4)
65-65: ✅ Good catch on the typo fix.Correcting "Build Etherpot" → "Build Etherspot" improves consistency and clarity throughout the config.
131-162: Slack notification formatting is well-structured.The expanded Slack message for both success and failure cases provides comprehensive test summary details (suites, passes, pending, failures, timing, and direct links to reports and jobs). This is valuable for quick diagnostics.
220-247: Confirm branch filter change is intentional.The branch filters for
installande2e-testshave been changed frome2e-modulartomaster. This is a significant behavioral change—these jobs will now only run on themasterbranch. Given the PR title mentionse2e-to-master, this appears intentional, but please confirm:
- The publishing workflow should now run only on
master(presumably for production releases).- You no longer want E2E tests running on the
e2e-modularbranch in this workflow.Additionally, the workflow orchestration looks sound:
install→testnet-e2e-tests→publish-npm-package→publish-github-release, with properrequiresdependencies.
167-203: All verification checks passed; no issues found.The
.circleci/announcePublish.shscript exists and is properly configured:
- ✅ Script exists at
.circleci/announcePublish.shand is tracked in the repository- ✅ The
chmod +xcommand at line 202 makes the script executable before running- ✅ The script correctly accepts and uses both arguments:
applicationName($1) andpackageversion ($2)- ✅ The version is properly extracted via
$(node -e "console.log(require('./package.json').version)")and passed as the second argument- ✅ The script has proper error handling and valid Slack webhook integration logic
The
bun publish --access publiccommand is also valid—Bun supports npm-compatible publishing commands.
| publish-github-release: | ||
| docker: | ||
| - image: ardd97/ghr | ||
| steps: | ||
| - checkout | ||
| - run: | ||
| name: Publish Release on GitHub | ||
| command: | | ||
| PACKAGE_VERSION="$(jq .version package.json -r)" | ||
| echo $PACKAGE_VERSION | ||
| ghr -t "${GITHUB_TOKEN}" -u "${CIRCLE_PROJECT_USERNAME}" -r "${CIRCLE_PROJECT_REPONAME}" -c "${CIRCLE_SHA1}" "$PACKAGE_VERSION" |
There was a problem hiding this comment.
🧩 Analysis chain
Verify Docker image provenance and ghr version stability.
The publish-github-release job uses the Docker image ardd97/ghr, which is not an official repository image. While it may be legitimate, consider:
- Verify the image is actively maintained and trustworthy.
- Pin to a specific image tag/digest rather than relying on
latest(implicit), to ensure reproducible builds and prevent supply-chain surprises if the image is updated. - The
ghrtool is invoked without an explicit version check. If the image doesn't specify a pinned version, future runs may pick up breaking changes.
For better security and stability, consider using an official GitHub Actions container or pinning the image to a specific digest.
🏁 Script executed:
#!/bin/bash
# Verify the image exists and check its latest tag info
# Check if the image is publicly available
docker pull ardd97/ghr:latest 2>&1 | head -5
# Attempt to determine the current tag and when it was last updated
curl -s https://hub.docker.com/v2/repositories/ardd97/ghr/tags | jq -r '.results[] | "\(.name) (updated: \(.last_updated))"' | head -10Length of output: 90
Replace unmaintained Docker image with current, pinned version.
The primary ghr tool is actively maintained (latest v0.17.0, Oct 2024), but the ardd97/ghr image itself is unmaintained since June 2021—over 3 years ago. The implicit latest tag pulls a stale container with outdated dependencies and potential security vulnerabilities.
Recommendations:
- Use
cibuilds/githubinstead, a lighter, maintained CircleCI convenience image with ghr pre-installed and pin to a specific version digest - Alternatively, replace the Docker image step with direct Go installation in the run command to fetch the latest ghr binary
- Pin both the image tag and ghr version to ensure reproducible, secure builds
🤖 Prompt for AI Agents
In .circleci/config.yml around lines 205 to 215 the job uses the unmaintained
ardd97/ghr Docker image (implicit latest) which is stale and insecure; replace
it with a maintained, pinned image (for example use cibuilds/github with a
specific digest or tagged version) or convert the step to a run step that
installs a specific ghr release (pin the ghr version) at runtime; ensure you
update the docker: image field to the chosen pinned image or add the
installation commands in the publish step, and document the pinned ghr version
so builds remain reproducible.
Description
Types of changes
What types of changes does your code introduce?
Further comments (optional)
Summary by CodeRabbit