chore: add .github and deny.toml and cliff.toml#1
Conversation
There was a problem hiding this comment.
Pull request overview
This PR adds configuration files for GitHub Actions workflows, dependency management, and project tooling to support automated releases, CI/CD pipelines, and development workflows for a Rust workspace project.
- Adds GitHub Actions workflows for CI, releases, dependency management, and changelog generation
- Introduces cargo-deny and git-cliff configuration for dependency auditing and changelog automation
- Includes development documentation (RELEASE.md, CONTRIBUTING.md) and a Makefile for common tasks
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
| deny.toml | Configures cargo-deny for dependency license and security auditing |
| cliff.toml | Configures git-cliff for automated changelog generation with conventional commits |
| RELEASE.md | Documents versioning strategy and release process for the project |
| Makefile | Provides convenient commands for building, testing, and publishing the project |
| CONTRIBUTING.md | Defines contribution guidelines and development workflow |
| .github/workflows/release.yml | Automates crate publishing and binary distribution on version tags |
| .github/workflows/dependabot-auto.yml | Enables automatic merging of minor Dependabot updates |
| .github/workflows/ci.yml | Runs comprehensive CI checks including tests, linting, and security audits |
| .github/workflows/auto-changelog.yml | Automatically generates and commits changelog on releases |
| .github/dependabot.yml | Configures Dependabot for Rust and GitHub Actions dependency updates |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| publish: ## Publish to crates.io manually | ||
| cargo publish -p dev-forge-core | ||
| @sleep 30 | ||
| cargo publish -p dev-forge |
There was a problem hiding this comment.
The manual publish command in the Makefile publishes dev-forge-core followed by dev-forge, but this differs from the automated release workflow which publishes dev-forge-core followed by dev-forge (not dev-forge-cli). However, the install command references dev-forge-cli. This naming inconsistency across different commands suggests a mismatch in package naming. Verify the correct package names and ensure consistency across all commands and workflows.
| cargo publish -p dev-forge | |
| cargo publish -p dev-forge-cli |
| - name: Commit CHANGELOG | ||
| run: | | ||
| git config user.name "github-actions[bot]" | ||
| git config user.email "github-actions[bot]@users.noreply.github.com" | ||
| git add CHANGELOG.md | ||
| git commit -m "chore: update CHANGELOG for ${{ github.ref_name }}" || exit 0 | ||
| git push origin HEAD:main No newline at end of file |
There was a problem hiding this comment.
The auto-changelog workflow attempts to push to the main branch after generating the changelog. This creates a potential issue: when a tag is pushed, this workflow generates a changelog and tries to commit it back to main. However, this commit happens AFTER the tag was already created, meaning the changelog update won't be included in the tagged release. Consider moving the changelog generation to happen before creating the tag, or restructure this workflow to update the changelog as part of the release preparation process.
| - name: Commit CHANGELOG | |
| run: | | |
| git config user.name "github-actions[bot]" | |
| git config user.email "github-actions[bot]@users.noreply.github.com" | |
| git add CHANGELOG.md | |
| git commit -m "chore: update CHANGELOG for ${{ github.ref_name }}" || exit 0 | |
| git push origin HEAD:main | |
| - name: Upload CHANGELOG artifact | |
| uses: actions/upload-artifact@v4 | |
| with: | |
| name: changelog-${{ github.ref_name }} | |
| path: CHANGELOG.md |
| cargo publish -p dev-forge-core --no-verify | ||
|
|
||
| - name: Wait for crates.io indexing | ||
| run: sleep 30 | ||
|
|
||
| - name: Publish dev-forge CLI | ||
| run: cargo publish -p dev-forge --no-verify |
There was a problem hiding this comment.
The release workflow uses --no-verify flag when publishing crates. This flag skips important verification steps that ensure the package can be built from the published tarball. While this might speed up publishing, it can lead to publishing broken packages that fail to install for users. Consider removing the --no-verify flag to ensure package integrity before publishing to crates.io.
| cargo publish -p dev-forge-core --no-verify | |
| - name: Wait for crates.io indexing | |
| run: sleep 30 | |
| - name: Publish dev-forge CLI | |
| run: cargo publish -p dev-forge --no-verify | |
| cargo publish -p dev-forge-core | |
| - name: Wait for crates.io indexing | |
| run: sleep 30 | |
| - name: Publish dev-forge CLI | |
| run: cargo publish -p dev-forge |
| steps: | ||
| - uses: actions/checkout@v4 | ||
| - uses: dtolnay/rust-toolchain@stable | ||
| - uses: Swatinem/rust-cache@v2 | ||
|
|
||
| - name: Publish dev-forge-core | ||
| run: | | ||
| cargo login ${{ secrets.CARGO_TOKEN }} | ||
| cargo publish -p dev-forge-core --no-verify |
There was a problem hiding this comment.
The CARGO_TOKEN secret is being passed directly to cargo login which will log the token in the command. While GitHub Actions masks secrets in logs, it's better practice to use the CARGO_REGISTRY_TOKEN environment variable instead, which cargo automatically recognizes without needing to call cargo login. This avoids any potential token exposure and simplifies the workflow.
| steps: | |
| - uses: actions/checkout@v4 | |
| - uses: dtolnay/rust-toolchain@stable | |
| - uses: Swatinem/rust-cache@v2 | |
| - name: Publish dev-forge-core | |
| run: | | |
| cargo login ${{ secrets.CARGO_TOKEN }} | |
| cargo publish -p dev-forge-core --no-verify | |
| env: | |
| CARGO_REGISTRY_TOKEN: ${{ secrets.CARGO_TOKEN }} | |
| steps: | |
| - uses: actions/checkout@v4 | |
| - uses: dtolnay/rust-toolchain@stable | |
| - uses: Swatinem/rust-cache@v2 | |
| - name: Publish dev-forge-core | |
| run: cargo publish -p dev-forge-core --no-verify |
| cargo publish -p dev-forge-core --no-verify | ||
|
|
||
| - name: Wait for crates.io indexing | ||
| run: sleep 30 |
There was a problem hiding this comment.
The 30-second wait between publishing crates may not be sufficient for crates.io to fully index the first crate before the second one is published. This can cause the second publish to fail if it depends on the first. The recommended wait time is typically 60-90 seconds. Consider increasing the sleep duration to at least 60 seconds to ensure reliable publishing.
| run: sleep 30 | |
| run: sleep 60 |
| @echo "✅ Release v$(VERSION) created! GitHub Actions will publish to crates.io" | ||
|
|
||
| install: ## Install binary locally | ||
| cargo install --path crates/dev-forge-cli --force |
There was a problem hiding this comment.
The Makefile references a crate path crates/dev-forge-cli in the install target, but the release workflow publishes a package named dev-forge (not dev-forge-cli). This inconsistency suggests either the install path is incorrect, or the package names don't match the directory structure. Ensure the crate path in the install command matches the actual workspace structure.
| cargo install --path crates/dev-forge-cli --force | |
| cargo install --path crates/dev-forge --force |
| git add . | ||
| git commit -m "chore: release v$(VERSION)" | ||
| git tag v$(VERSION) | ||
| git push origin main --tags |
There was a problem hiding this comment.
The release target pushes to origin main but the CONTRIBUTING.md document states that PRs should target the dev branch. This inconsistency in branching strategy can lead to confusion. Consider either updating the release target to push to the correct branch, or clarifying in the documentation which branch should be used for releases versus regular development.
| git push origin main --tags | |
| git push origin dev --tags |
No description provided.