-
-
Notifications
You must be signed in to change notification settings - Fork 7
Makes the release script better. #112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
WalkthroughThe pull request updates the Changes
Sequence Diagram(s)sequenceDiagram
participant U as User
participant S as Build Script
participant G as Git
participant FS as File System
U->>S: Execute build_steam_release.sh
S->>G: Checkout specified branch
S->>G: Pull latest changes
S->>G: Update submodules recursively
S->>G: Check repository status
alt Repository not clean
S->>U: Output error and exit (status 1)
else Repository clean
S->>FS: Remove existing Linux/Windows build directories
S->>FS: Create new build directories
S->>U: Proceed with build operations
end
Possibly related PRs
Poem
✨ Finishing Touches
🪧 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
scripts/build_steam_release.sh (1)
51-55: Repository Cleanliness Check.
The script correctly verifies that the repository is clean before proceeding, helping to prevent accidental releases from a dirty state. For enhanced readability and POSIX best practices, consider using the-ntest operator instead of! -z. For example:-if [ ! -z "$(git status --porcelain)" ]; then +if [ -n "$(git status --porcelain)" ]; then
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
scripts/build_steam_release.sh(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (11)
- GitHub Check: build (macos-latest, Debug, gcc)
- GitHub Check: build (macos-latest, Release, gcc)
- GitHub Check: build (macos-latest, Debug, clang)
- GitHub Check: build (ubuntu-latest, Release, mingw-w64-gcc)
- GitHub Check: build (ubuntu-latest, Debug, clang)
- GitHub Check: build (ubuntu-latest, Release, clang)
- GitHub Check: build (macos-latest, Release, clang)
- GitHub Check: build (ubuntu-latest, Debug, mingw-w64-gcc)
- GitHub Check: build (ubuntu-latest, Release, gcc)
- GitHub Check: build (ubuntu-latest, Debug, gcc)
- GitHub Check: Analyze (c-cpp)
🔇 Additional comments (2)
scripts/build_steam_release.sh (2)
46-50: Branch Checkout and Submodule Update.
The added commands ensure that the master branch is checked out and updated, and that submodules are initialized recursively. This helps guarantee that the build uses the latest code. However, consider that if there are local modifications, the checkout or pull might fail—even though later you check for a clean repository. You might want to add an early check for uncommitted changes prior to performing the checkout and pull.
56-59: Clearing Old Build Directories.
The removal of old Steam build content directories ensures that any stale artifacts are cleared out before creating new ones, which is essential for a consistent release package. This approach is solid and adheres to best practices.
1ade200 to
c11e1a8
Compare
The release script will now attempt to checkout all things needed for the build from the correct branch. It should also prevent releases from dirty repositories.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
scripts/build_steam_release.sh (1)
37-40: Optional Parameterization and Status Echo
The introduction of optional parameters (GIT_BRANCHdefaulting tomasterandBUILD_TYPEdefaulting toRelease) increases the script’s configurability as intended. The accompanying echo message (line 40) clearly informs the user which branch and build type will be used.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
scripts/build_steam_release.sh(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (11)
- GitHub Check: build (macos-latest, Release, gcc)
- GitHub Check: build (ubuntu-latest, Debug, clang)
- GitHub Check: build (ubuntu-latest, Release, mingw-w64-gcc)
- GitHub Check: build (macos-latest, Debug, clang)
- GitHub Check: build (ubuntu-latest, Debug, mingw-w64-gcc)
- GitHub Check: build (macos-latest, Debug, gcc)
- GitHub Check: build (macos-latest, Release, clang)
- GitHub Check: build (ubuntu-latest, Release, clang)
- GitHub Check: build (ubuntu-latest, Debug, gcc)
- GitHub Check: build (ubuntu-latest, Release, gcc)
- GitHub Check: Analyze (c-cpp)
🔇 Additional comments (5)
scripts/build_steam_release.sh (5)
51-55: Branch Checkout and Submodules Update
This block checks out the specified branch, pulls the latest changes, and updates submodules recursively. Leveragingset -eensures that any errors in these steps will abort the script immediately, aligning perfectly with the updated release process.
56-59: Repository Cleanliness Check
The added check usinggit status --porcelainsuccessfully prevents the release process from proceeding if there are uncommitted changes. This ensures that releases are made only from a clean repository state, directly addressing one of the PR objectives.
61-64: Old Build Cleanup
Clearing out old build directories (for both Linux and Windows content) before initiating a new build is a solid enhancement. This cleanup helps avoid conflicts with stale artifacts and ensures a fresh build environment.
72-73: Dynamic Build Type Configuration for Linux
Replacing the hardcoded build type with theBUILD_TYPEvariable in the Linux build configuration improves the script’s flexibility and supports multiple build configurations as required.
85-86: Dynamic Build Type Configuration for Windows
Similarly, using theBUILD_TYPEvariable for the Windows build guarantees consistency across platforms and enhances the overall configurability of the build process.
The release script will now attempt to checkout all things needed for
the build from the correct branch. It should also prevent releases from
dirty repositories.
Summary by CodeRabbit