#68: proper ci cd for npm package publishing #1012
Conversation
…ily updates for npm packages in various directories
… 2.0.0-alpha.1 feat(release): define package names and components in release main config file feat(release): set up configuration for automated versioning and release process
…pull request, and schedule events targeting main, develop, and release/* branches. Set permissions for job execution and analysis. Include steps to harden runner, checkout repository, initialize CodeQL, autobuild, and perform CodeQL analysis for javascript and typescript languages.
feat(workflows): configure release workflow to trigger on push to main, dev, and release branches feat(workflows): set permissions for contents to read and write in release job feat(workflows): add steps to harden runner for runtime security in release job feat(workflows): add release-please-action for automated releases in release job feat(workflows): add actions/checkout and actions/setup-node for release job setup feat(workflows): add pnpm installation and publishing steps in release job
…or Microsoft Defender For DevOps security checks
…workflow to scan and block PRs with known-vulnerable packages
…sing OSSAR feat(security-ossar.yml): integrate open source static analysis tools with GitHub code scanning feat(security-ossar.yml): schedule security scans on main, develop, and release branches
…y scorecard analysis to enhance supply-chain security monitoring and compliance with best practices
filtering for push and pull_request events to align with project requirements
…lease-please-action configuration
…cores instead of spaces for consistency and readability.
…n to use underscore instead of space for consistency across components
Release-As: 2.0.0
|
Thanks for working on this @TGTGamer ! I've wanted to have such a nice workflow for a long time. I'm new to release-please and still checking documentation, but it looks very neat. Let me dig into your change and ask questions in the review. |
I've added a bunch of comments (questions more precisely 😄). You're definitely at an expert level with properly configuring an OSS project. I'm learning a lot from this PR! |
WalkthroughWalkthroughThe updates introduce a suite of GitHub Actions workflows and configurations to automate dependency management, security analysis, static code analysis, and the release process. These changes enhance the project's CI/CD pipeline by ensuring up-to-date dependencies, secure codebase, compliance, and streamlined release automation. The project now includes automated testing and deployment configurations, addressing key objectives for improving npm package publishing workflows. Changes
Related issues
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
Probably because it's on a fork. Bet once it merged over it would sort itself out :) |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 6
Configuration used: CodeRabbit UI
Files selected for processing (10)
- .github/dependabot.yml (1 hunks)
- .github/release/.release-manifest.json (1 hunks)
- .github/release/release-main-config.json (1 hunks)
- .github/workflows/build-test.yml (1 hunks)
- .github/workflows/codeql.yml (1 hunks)
- .github/workflows/management-changelog.yml (1 hunks)
- .github/workflows/security-defender-for-devops.yml (1 hunks)
- .github/workflows/security-dependency-review.yml (1 hunks)
- .github/workflows/security-ossar.yml (1 hunks)
- .github/workflows/security-scorecard.yml (1 hunks)
Files skipped from review due to trivial changes (2)
- .github/dependabot.yml
- .github/release/.release-manifest.json
Additional comments: 19
.github/workflows/security-dependency-review.yml (2)
- 11-13: The trigger event
merge_groupis specified but not standard in GitHub Actions. Verify if this is a custom event or a typo. Standard events includepush,pull_request, etc.- 31-31: The use of a conditional operator to choose between
secrets.BOT_TOKENandgithub.tokenis a good practice for flexibility. However, ensure thatBOT_TOKENhas the necessary permissions for the actions being performed..github/release/release-main-config.json (2)
- 1-59: The configuration file is well-structured and follows best practices for managing releases in a monorepo setup. The use of
"separate-pull-requests": trueallows for granular control over package releases, which is beneficial in a monorepo environment.- 56-56: Given the previous discussion between
ymc9andTGTGamerregarding theseparate-pull-requestssetting, it's good to see the decision documented and implemented in the configuration. This decision should be revisited periodically to ensure it continues to meet the project's needs..github/workflows/management-changelog.yml (2)
- 46-46: The use of
google-github-actions/release-please-actionwith a specific configuration file is a good practice for automating release management. Ensure that the.github/release/release-main-config.jsonand.github/release/.release-manifest.jsonfiles are correctly set up and maintained.- 61-61: The decision to use
pnpm publish-allfor publishing indicates a streamlined process for handling package releases. However, ensure that this script is well-documented and that its implications on the release process are fully understood by all contributors..github/workflows/security-defender-for-devops.yml (3)
- 11-12: The note about MSDO currently being in beta and running on
windows-latestwith upcomingubuntu-latestsupport is important for future planning. Keep an eye on updates to expand support and improve the workflow's compatibility.- 16-18: The trigger events are well-defined, covering
pushandpull_requestfor relevant branches, and a scheduled run. This ensures regular security checks alongside development activities.- 59-59: The use of
actions/setup-dotnetto install multiple versions of .NET is a good practice for ensuring compatibility across different versions. Ensure that all projects within the repository are compatible with these versions..github/workflows/security-ossar.yml (2)
- 12-14: The trigger events are well-defined, covering both direct code changes (
push,pull_request) and a scheduled run. This ensures that the codebase is regularly scanned for vulnerabilities.- 72-72: Uploading OSSAR results to the Security tab is a good practice for visibility and tracking of security issues. Ensure that the SARIF file path is correctly specified and that the
security-eventspermission is appropriately set..github/workflows/codeql.yml (2)
- 4-6: The trigger events are well-defined, covering both direct code changes (
push,pull_request) and a scheduled run. This ensures that the codebase is regularly scanned for vulnerabilities.- 74-74: The final step of performing CodeQL analysis is crucial for identifying vulnerabilities. Ensure that the analysis covers all relevant languages and that the results are reviewed and acted upon.
.github/workflows/build-test.yml (4)
- 11-13: The trigger events are well-defined, covering both direct code changes (
push,pull_request) and a custommerge_group. Verify ifmerge_groupis a custom event or a typo. Standard events includepush,pull_request, etc.- 25-25: Setting permissions to read-only for contents is a good security practice, minimizing the risk of unauthorized modifications during the CI process.
- 27-27: The
build-testjob is configured to run on a specific runner (buildjet-8vcpu-ubuntu-2204). Ensure that this runner has the necessary resources and is available for the project.- 8-29: > 📝 NOTE
This review was outside the diff hunks, and no overlapping diff hunk was found. Original lines [61-61]
The use of
pnpm publish-allfor publishing indicates a streamlined process for handling package releases. However, ensure that this script is well-documented and that its implications on the release process are fully understood by all contributors..github/workflows/security-scorecard.yml (2)
- 8-10: The workflow is named appropriately and focuses on supply-chain security, which is crucial for modern software development. The trigger events include a schedule and branch-specific triggers, ensuring regular and relevant analysis.
- 77-77: Uploading the results to GitHub's code scanning dashboard is a good practice for visibility and tracking of security issues. Ensure that the SARIF file path is correctly specified and that the
security-eventspermission is appropriately set.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (5)
- .github/workflows/codeql.yml (1 hunks)
- .github/workflows/security-defender-for-devops.yml (1 hunks)
- .github/workflows/security-dependency-review.yml (1 hunks)
- .github/workflows/security-ossar.yml (1 hunks)
- .github/workflows/security-scorecard.yml (1 hunks)
Files skipped from review as they are similar to previous changes (5)
- .github/workflows/codeql.yml
- .github/workflows/security-defender-for-devops.yml
- .github/workflows/security-dependency-review.yml
- .github/workflows/security-ossar.yml
- .github/workflows/security-scorecard.yml
|
This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation. |
Caution
Intentionally targetting V2 branch:
If accepting this PR, please ensure that you either REBASE the commits or follow the below steps for first release
CLOSES: #68
New Features
Chores
Documentation
Examples
How should I write my commits?
Release Please assumes you are using Conventional Commit messages.
The most important prefixes you should have in mind are:
fix:which represents bug fixes, and correlates to a SemVerpatch.
feat:which represents a new feature, and correlates to a SemVer minor.feat!:, orfix!:,refactor!:, etc., which represent a breaking change(indicated by the
!) and will result in a SemVer major.Linear git commit history (use squash-merge)
We highly recommend that you use squash-merges when merging pull requests.
Further info found here: https://github.com/googleapis/release-please
I am ready to release V2.
Amazing, we are all looking forward to it. To start using release-please all you need to do is REBASE this PR onto the v2 branch. This will ensure that the "chore: release 2.0.0" commit is the last commit on your branch.
If you then plan on merging V2 into Main you should follow one of these below steps:
REBASE - Keeps the commit at the top, ensuring that release-please knows to release at V2.
SQUASH - Name the PR "chore: release 2.0.0" and include "Release-As: 2.0.0" within the message.
POST-PR COMMIT - Make a new commit post PR merge to main to link to V2.
git commit --allow-empty -m "chore: release 2.0.0" -m "Release-As: 2.0.0"I try to follow the OpenSSF Best Practices Gold Level. Files I create automatically generate a License Statement. Please feel free to remove these if you desire - or ask me to :)
Summary by CodeRabbit