mirror of
https://github.com/adamhathcock/sharpcompress.git
synced 2026-04-22 22:19:37 +00:00
9794c8ba72
- Removed create-release build target from build/Program.cs - Removed CreateRelease constant - Removed "Create GitHub Release" step from workflow - Removed permissions: contents: write since no longer creating releases - Updated NUGET_RELEASE.md to remove all references to GitHub release creation - Updated TESTING.md to remove GitHub release verification steps - GitHub releases will now be created manually instead of automatically Co-authored-by: adamhathcock <527620+adamhathcock@users.noreply.github.com>
121 lines
4.0 KiB
Markdown
121 lines
4.0 KiB
Markdown
# Testing Guide for NuGet Release Workflow
|
|
|
|
This document describes how to test the NuGet release workflow.
|
|
|
|
## Testing Strategy
|
|
|
|
Since this workflow publishes to NuGet.org and requires repository secrets, testing should be done carefully. The workflow runs on both Windows and Ubuntu, but only the Windows build publishes to NuGet.
|
|
|
|
## Pre-Testing Checklist
|
|
|
|
- [x] Workflow YAML syntax validated
|
|
- [x] Version determination logic tested locally
|
|
- [x] Version update logic tested locally
|
|
- [x] Build script works (`dotnet run --project build/build.csproj`)
|
|
|
|
## Manual Testing Steps
|
|
|
|
### 1. Test Prerelease Publishing (Recommended First Test)
|
|
|
|
This tests the workflow on untagged commits to the master or release branch.
|
|
|
|
**Steps:**
|
|
1. Ensure `NUGET_API_KEY` secret is configured in repository settings
|
|
2. Create a test commit on the `master` or `release` branch (e.g., update a comment or README)
|
|
3. Push to the `master` or `release` branch
|
|
4. Monitor the GitHub Actions workflow at: https://github.com/adamhathcock/sharpcompress/actions
|
|
5. Verify:
|
|
- Workflow triggers and runs successfully on both Windows and Ubuntu
|
|
- Version is determined correctly (e.g., `0.43.0-beta.XXX` if last tag is 0.42.x)
|
|
- Build and tests pass on both platforms
|
|
- Package artifacts are uploaded for both platforms
|
|
- Package is pushed to NuGet.org as prerelease (Windows build only)
|
|
|
|
**Expected Outcome:**
|
|
- A new prerelease package appears on NuGet.org: https://www.nuget.org/packages/SharpCompress/
|
|
- Package version follows pattern: `{NEXT_MINOR_VERSION}-beta.{COMMIT_COUNT}`
|
|
|
|
### 2. Test Tagged Release Publishing
|
|
|
|
This tests the workflow when a version tag is pushed.
|
|
|
|
**Steps:**
|
|
1. Prepare the `master` or `release` branch with all desired changes
|
|
2. Create a version tag (must be a pure semantic version like `MAJOR.MINOR.PATCH`):
|
|
```bash
|
|
git checkout master # or release
|
|
git tag 0.42.2
|
|
git push origin 0.42.2
|
|
```
|
|
3. Monitor the GitHub Actions workflow
|
|
4. Verify:
|
|
- Workflow triggers and runs successfully on both Windows and Ubuntu
|
|
- Version is determined as the tag (e.g., `0.42.2`)
|
|
- Build and tests pass on both platforms
|
|
- Package artifacts are uploaded for both platforms
|
|
- Package is pushed to NuGet.org as stable release (Windows build only)
|
|
|
|
**Expected Outcome:**
|
|
- A new stable release package appears on NuGet.org
|
|
- Package version matches the tag
|
|
|
|
### 3. Test Duplicate Package Handling
|
|
|
|
This tests the `--skip-duplicate` flag behavior.
|
|
|
|
**Steps:**
|
|
1. Push to the `release` branch without making changes
|
|
2. Monitor the workflow
|
|
3. Verify:
|
|
- Workflow runs but NuGet push is skipped with "duplicate" message
|
|
- No errors occur
|
|
|
|
### 4. Test Build Failure Handling
|
|
|
|
This tests that failed builds don't publish packages.
|
|
|
|
**Steps:**
|
|
1. Introduce a breaking change in a test or code
|
|
2. Push to the `release` branch
|
|
3. Verify:
|
|
- Workflow runs and detects the failure
|
|
- Build or test step fails
|
|
- NuGet push step is skipped
|
|
- No package is published
|
|
|
|
## Verification
|
|
|
|
After each test, verify:
|
|
|
|
1. **GitHub Actions Logs**: Check the workflow logs for any errors or warnings
|
|
2. **NuGet.org**: Verify the package appears with correct version and metadata
|
|
3. **Artifacts**: Download and inspect the uploaded artifacts
|
|
|
|
## Rollback/Cleanup
|
|
|
|
If testing produces unwanted packages:
|
|
|
|
1. **Prerelease packages**: Can be unlisted on NuGet.org (Settings → Unlist)
|
|
2. **Stable packages**: Cannot be deleted, only unlisted (use test versions)
|
|
3. **Tags**: Can be deleted with:
|
|
```bash
|
|
git tag -d 0.42.2
|
|
git push origin :refs/tags/0.42.2
|
|
```
|
|
|
|
## Known Limitations
|
|
|
|
- NuGet.org does not allow re-uploading the same version
|
|
- Deleted packages on NuGet.org reserve the version number
|
|
- The workflow requires the `NUGET_API_KEY` secret to be set
|
|
|
|
## Success Criteria
|
|
|
|
The workflow is considered successful if:
|
|
|
|
- ✅ Prerelease versions are published correctly with beta suffix
|
|
- ✅ Tagged versions are published as stable releases
|
|
- ✅ Build and test failures prevent publishing
|
|
- ✅ Duplicate packages are handled gracefully
|
|
- ✅ Workflow logs are clear and informative
|