fix: add semantic-release version to open api file #22
Conversation
WalkthroughThe changes in this pull request focus on enhancing the CI/CD pipeline and application configuration for the Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant CI/CD Pipeline
participant Docker
participant Swagger
participant Application
User->>CI/CD Pipeline: Trigger build
CI/CD Pipeline->>Docker: Build image with API_VERSION
Docker->>CI/CD Pipeline: Image built
CI/CD Pipeline->>Terraform: Create .auto.tfvars with image version
CI/CD Pipeline->>Swagger: Update documentation with assembly version
Swagger->>Application: Serve updated API documentation
Application->>User: Respond with Swagger UI
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 using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (4)
src/Bmb.Production.Api/Dockerfile (2)
21-22: LGTM! Version injection implementation looks correct.The addition of
API_VERSIONbuild argument and its usage in thedotnet publishcommand is the right approach for injecting the semantic version into the assembly.Consider adding a comment above the ARG declaration to document its purpose and expected format:
+# API_VERSION: Semantic version (e.g., 1.0.0) injected during build by semantic-release ARG API_VERSION
Line range hint
9-10: Consider documenting the port change decision.While not part of this PR's changes, there are commented-out port exposures (8080/8081). If these are meant to be permanently replaced by 80/443, consider removing the commented lines or adding a comment explaining the decision.
src/Bmb.Production.Api/Program.cs (1)
Line range hint
1-97: Well-structured application setup following Clean ArchitectureThe application configuration demonstrates good practices:
- Proper separation of concerns using extension methods
- Comprehensive error handling with global exception handler
- Health checks integration
- Structured logging with environment enrichment
Consider adding API versioning middleware (e.g., Microsoft.AspNetCore.Mvc.Versioning) to complement the Swagger versioning for proper API version management.
🧰 Tools
🪛 GitHub Check: build-and-test
[warning] 53-53:
The type 'Bmb.Auth.JwtOptions?' cannot be used as type parameter 'TService' in the generic type or method 'ServiceCollectionServiceExtensions.AddSingleton(IServiceCollection, TService)'. Nullability of type argument 'Bmb.Auth.JwtOptions?' doesn't match 'class' constraint.
[warning] 66-66:
Dereference of a possibly null reference..github/workflows/build-and-deploy.yaml (1)
169-170: LGTM! Consider adding version validation.The addition of the API_VERSION build argument is good. However, consider adding validation to ensure the version format is correct before passing it to the Docker build.
build-args: | - API_VERSION=${{ steps.sanitize-version.outputs.version }} + API_VERSION=$(echo "${{ steps.sanitize-version.outputs.version }}" | grep -E '^[0-9]+\.[0-9]+\.[0-9]+(-[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*)?(\+[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*)?$' || echo '0.0.0')
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
.github/workflows/build-and-deploy.yaml(1 hunks)src/Bmb.Production.Api/Dockerfile(1 hunks)src/Bmb.Production.Api/Extensions/SwaggerExtensions.cs(1 hunks)src/Bmb.Production.Api/Program.cs(4 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
src/Bmb.Production.Api/Extensions/SwaggerExtensions.cs (1)
Pattern **/*.cs: Validate all files and structures against Domain Driven Design, SOLID and Clean Architecture principles.
src/Bmb.Production.Api/Program.cs (1)
Pattern **/*.cs: Validate all files and structures against Domain Driven Design, SOLID and Clean Architecture principles.
🪛 GitHub Check: build-and-test
src/Bmb.Production.Api/Extensions/SwaggerExtensions.cs
[warning] 16-16:
Dereference of a possibly null reference.
src/Bmb.Production.Api/Program.cs
[warning] 66-66:
Dereference of a possibly null reference.
🔇 Additional comments (5)
src/Bmb.Production.Api/Extensions/SwaggerExtensions.cs (2)
Line range hint 8-45: LGTM - Clean Architecture and SOLID Principles
The code follows Clean Architecture principles:
- Properly placed in Extensions namespace
- Follows Single Responsibility Principle
- Uses dependency injection via extension methods
- Correctly scoped as internal infrastructure code
🧰 Tools
🪛 GitHub Check: build-and-test
[warning] 16-16:
Dereference of a possibly null reference.
16-18: Consider semantic versioning format validation
While the version formatting looks good, consider validating if the version follows semantic versioning (SemVer) format since this is being used in the API documentation.
Let's verify the version format in other files:
✅ Verification successful
Version format follows semantic versioning and is properly sourced
The version format used in the Swagger documentation is correctly following semantic versioning (Major.Minor.Build) and is properly sourced from the executing assembly's version. This is evident from:
- The version is obtained from the assembly version:
Assembly.GetExecutingAssembly().GetName().Version - The version components are properly used in both the Swagger endpoint URL and documentation:
- Swagger endpoint:
$"/swagger/v{version}/swagger.yaml" - API Info:
Version = $"v{version.Major}.{version.Minor}.{version.Build}"
- Swagger endpoint:
- The version is controlled through the build process as seen in the Dockerfile:
/p:Version=$API_VERSION
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for version format in csproj files and other potential version sources
rg -g "*.csproj" -A 2 "<Version>|<AssemblyVersion>"
rg -g "*.props" -A 2 "<Version>|<AssemblyVersion>"
Length of output: 255
Script:
#!/bin/bash
# Let's try a broader search for project files and version-related patterns
fd -e csproj .
Length of output: 781
Script:
#!/bin/bash
# Search for version-related code in the entire codebase
rg -g "!{bin,obj}/*" "Version\s*=|AssemblyVersion|FileVersion"
Length of output: 9381
Script:
#!/bin/bash
# Look for the specific version usage in swagger configuration
ast-grep --pattern 'SwaggerDoc($_, new OpenApiInfo { $$$'
Length of output: 59
Script:
#!/bin/bash
# Let's check the API version configuration and assembly info
cat src/Bmb.Production.Api/Bmb.Production.Api.csproj
# Also check for version configuration in Program.cs or Startup.cs
fd -e cs -x cat {} \; -g "*Program.cs"
Length of output: 4951
🧰 Tools
🪛 GitHub Check: build-and-test
[warning] 16-16:
Dereference of a possibly null reference.
src/Bmb.Production.Api/Program.cs (2)
43-43: LGTM! Good practice using JsonStringEnumConverter
The JSON configuration is properly streamlined and the use of JsonStringEnumConverter ensures proper enum serialization in the API responses.
56-56: LGTM! Proper middleware ordering
The middleware pipeline is correctly ordered for security (HTTPS -> CORS -> Authentication -> Authorization).
Also applies to: 76-76, 80-80, 82-82
.github/workflows/build-and-deploy.yaml (1)
Line range hint 91-112: Review error handling in semantic-release job.
The semantic-release job uses continue-on-error: true and has a fallback mechanism for version retrieval, but there are potential issues:
- The error check
if [ $? -ne 0 ]might not catch all failure cases since it's after multiple commands - The fallback mechanism assumes the repository has at least one release
Consider restructuring the error handling:
- name: Release
id: semantic-release
- continue-on-error: true
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
+ set -e
npx semantic-release
- if [ -f VERSION ]; then
- VERSION=$(cat VERSION)
- else
- echo "VERSION file not found, getting latest version from latest release"
- VERSION=$(curl -s https://api.github.com/repos/${{ github.repository }}/releases/latest | jq -r '.tag_name' | sed 's/v//')
- fi
- echo "version=$VERSION" >> $GITHUB_OUTPUT
-
- if [ $? -ne 0 ]; then
- echo "Release failed, getting latest version from lates release"
- echo "version=$(curl -s https://api.github.com/repos/${{ github.repository }}/releases/latest | jq -r '.tag_name' | sed 's/v//')" >> $GITHUB_OUTPUT
- fi
+ VERSION=$(cat VERSION 2>/dev/null || curl -sf https://api.github.com/repos/${{ github.repository }}/releases/latest | jq -r '.tag_name' | sed 's/v//' || echo "0.0.0")
+ echo "version=$VERSION" >> $GITHUB_OUTPUT✅ Verification successful
Let me verify the semantic-release configuration to understand the complete setup.
Let me check the actual workflow file to see the complete context of the release job.
Improve error handling in semantic-release job to handle first-time releases
The review comment is correct. The current implementation has several issues:
- The repository has no releases yet (confirmed by the API check), which means the fallback mechanism will fail.
- The
$?check is placed after multiple commands, making it unreliable for error detection. - Using
continue-on-error: truewithout proper error handling can mask critical failures.
The suggested fix in the review is appropriate as it:
- Removes
continue-on-errorto prevent masking critical failures - Uses
set -eto fail fast on any error - Provides a safe fallback to "0.0.0" when no releases exist
- Simplifies the version extraction using a single command chain with proper error handling
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if the repository has any releases
gh api repos/$GITHUB_REPOSITORY/releases/latest -q '.tag_name' 2>/dev/null || echo "No releases found - fallback mechanism will fail"
Length of output: 240
Script:
#!/bin/bash
# Check for semantic-release config files
fd -e json -e yaml -e yml -e js -e cjs -e mjs -e config.js -e config.cjs -e config.mjs -e rc -e rc.js -e rc.json -e rc.yaml -e rc.yml --exec echo "=== {} ===" --exec cat {}
# Check package.json for semantic-release config and dependencies
fd package.json --exec echo "=== {} ===" --exec cat {}
Length of output: 814
Script:
#!/bin/bash
# Check the complete workflow file
cat .github/workflows/build-and-deploy.yaml
Length of output: 8350
| { | ||
| internal static void SetupSwagger(this IServiceCollection services) | ||
| { | ||
| var version = Assembly.GetExecutingAssembly().GetName().Version; |
There was a problem hiding this comment.
Add null check for assembly version
The assembly version might be null in some edge cases. Add a null check to prevent potential runtime exceptions.
Apply this diff:
-var version = Assembly.GetExecutingAssembly().GetName().Version;
+var version = Assembly.GetExecutingAssembly().GetName().Version
+ ?? throw new InvalidOperationException("Assembly version is not available");📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| var version = Assembly.GetExecutingAssembly().GetName().Version; | |
| var version = Assembly.GetExecutingAssembly().GetName().Version | |
| ?? throw new InvalidOperationException("Assembly version is not available"); |
| options.SwaggerEndpoint($"/swagger/v{version}/swagger.yaml", $"v{version}"); | ||
| }); | ||
| } | ||
|
|
||
| app.UseHealthChecks("/healthz", new HealthCheckOptions |
There was a problem hiding this comment.
Add null checks for assembly version
The current implementation might throw a NullReferenceException if the assembly version is not set.
Consider adding null checks:
- var version = Assembly.GetExecutingAssembly().GetName().Version.Major;
+ var assemblyVersion = Assembly.GetExecutingAssembly().GetName().Version;
+ var version = assemblyVersion?.Major ?? 1; // Fallback to version 1 if not set
options.SwaggerEndpoint($"/swagger/v{version}/swagger.yaml", $"v{version}");📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| app.UseSwaggerUI(options => | |
| { | |
| var version = Assembly.GetExecutingAssembly().GetName().Version.Major; | |
| options.SwaggerEndpoint($"/swagger/v{version}/swagger.yaml", $"v{version}"); | |
| }); | |
| app.UseSwaggerUI(options => | |
| { | |
| var assemblyVersion = Assembly.GetExecutingAssembly().GetName().Version; | |
| var version = assemblyVersion?.Major ?? 1; // Fallback to version 1 if not set | |
| options.SwaggerEndpoint($"/swagger/v{version}/swagger.yaml", $"v{version}"); | |
| }); |
🧰 Tools
🪛 GitHub Check: build-and-test
[warning] 66-66:
Dereference of a possibly null reference.
|
|
🎉 This PR is included in version 1.1.6 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version 1.1.7 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
No description provided.