Fix github actions issue with --framework default value change (#9230) #9231
Conversation
WalkthroughThe changes in this pull request involve modifications to two GitHub Actions workflow configuration files, specifically targeting the Changes
Assessment against linked issues
Poem
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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
.github/workflows/bit.full.ci.yml (3)
163-163: Maintain consistency in framework versions for storage testsSimilar to the database tests, the storage test projects use different framework versions:
- TestLocal:
net8.0- TestAzureBlobStorage:
net9.0Consider using the same framework version for both storage options to ensure consistent behavior and testing.
Also applies to: 167-167
173-173: Consider architectural implications of mixed framework versionsThe backend setup tests also use different framework versions:
- Standalone API:
net8.0- Integrated API:
net9.0This pattern of mixing framework versions across different test configurations suggests a need for a clear framework versioning strategy. Consider:
- Documenting the rationale for framework version choices
- Creating a matrix strategy in the workflow to test each configuration with both framework versions
- Using environment variables to control framework versions centrally
Also applies to: 180-180
Line range hint
64-219: Consider implementing a structured framework version strategyWhile the PR successfully adds the
--frameworkparameter to all template commands, the alternating use ofnet8.0andnet9.0across different test configurations suggests a need for a more structured approach. Consider:
- Using GitHub Actions matrix strategy to test each configuration with both framework versions
- Adding workflow inputs to control framework versions:
on: workflow_dispatch: inputs: framework-version: description: 'Target framework version' required: true default: 'net8.0' type: choice options: - net8.0 - net9.0
- Using environment variables to centrally manage framework versions:
env: DEFAULT_FRAMEWORK: net8.0 PREVIEW_FRAMEWORK: net9.0This would make the framework version choices more maintainable and easier to update in the future.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
.github/workflows/bit.full.ci.yml(6 hunks).github/workflows/todo-sample.cd.yml(4 hunks)
🔇 Additional comments (7)
.github/workflows/bit.full.ci.yml (4)
64-64: Framework version correctly specified for SimpleTest
The --framework net8.0 parameter matches the test execution environment, ensuring consistency between project creation and test execution.
219-219: Framework version correctly specified for empty template
The use of --framework net8.0 for the SSR per page template is appropriate as it uses the stable framework version.
107-107: Consider standardizing framework versions across database tests
The database test projects use a mix of net8.0 and net9.0 frameworks. While both versions are supported by the workflow (as evidenced by the global.json setup), using preview versions (net9.0) in some tests but not others could lead to inconsistent test coverage and potential compatibility issues.
Consider standardizing all tests to use net8.0 for stability, or document the reasoning behind using different framework versions for different database tests.
Let's check the framework requirements in the repository:
Also applies to: 127-127, 145-145, 153-153
186-186: Clarify framework version selection criteria
The sample configurations use different framework versions:
- Full-featured configuration (TestProject):
net9.0 - Minimal configuration (TestProject2):
net8.0
Is there a specific reason for using different framework versions based on the feature set? This should be documented if intentional, or standardized if not.
Let's check if this pattern exists elsewhere:
Also applies to: 191-191
.github/workflows/todo-sample.cd.yml (3)
45-45: Framework specification is consistently applied across all jobs
The addition of --framework net8.0 to all dotnet new bit-bp commands aligns with the PR objective of fixing the framework default value issue. The change is consistently applied across all build jobs (API+Blazor, Windows, Android, iOS).
Also applies to: 143-143, 212-212, 312-312
312-312: Verify cross-platform framework consistency
The framework specifications are consistent across all platforms (Web, Windows, Android, iOS). Let's verify that all platform-specific framework targets are correctly aligned with the base .NET 8.0 framework.
#!/bin/bash
# Description: Verify framework consistency across platforms
# Check framework specifications in project files
echo "Checking framework specifications in project files:"
find TodoSample/src -name "*.csproj" -exec grep -l "TargetFramework" {} \; -exec grep "TargetFramework" {} \;143-143: Verify Windows desktop framework configuration
The Windows build correctly specifies both .NET 8.0 for project creation and appropriate frameworks (net8.0-x86-desktop,webview2) for VPK packaging. However, let's verify that these framework specifications are compatible.
msynk
deleted the
9230-github-actions-are-issue-with-new-framework-default-value-change
branch
This closes #9230
Summary by CodeRabbit