Publish-WikiContent: Check if git command was successful
#173
Conversation
WalkthroughThe changes add validation to the Publish-WikiContent script to verify that the git add command succeeds before proceeding with subsequent git operations (commit, tag, push). If git add fails, the script logs an error and skips the remaining operations rather than continuing and failing downstream. A new localized error message supports this validation, and CHANGELOG.md documents the fix. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Pre-merge checks❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
CHANGELOG.md (1)
16-20: Unreleased changelog entry is correct; optional tweak to issue link textThe new
### Fixedentry under[Unreleased]is well‑placed, concise, and correctly references #172; it also respects the “Keep a Changelog” and “≤2 items per change type” guidance.
If you want to align more strictly with the documented style, you could change the link text toissue #172to match the recommended[issue #<number>]format, but this is purely cosmetic given existing entries.Based on learnings
source/en-US/DscResource.DocGenerator.strings.psd1 (1)
3-29: New localized GitAddFailedMessage looks goodThe
GitAddFailedMessageentry is correctly localized and matches surrounding formatting and naming conventions in this file. No functional issues.If you later adopt the
(PREFIX####)ID pattern in this module, this would be a good candidate to update at the same time, but it’s not blocking.Based on learnings
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
CHANGELOG.md(1 hunks)source/Public/Publish-WikiContent.ps1(1 hunks)source/en-US/DscResource.DocGenerator.strings.psd1(1 hunks)
🧰 Additional context used
📓 Path-based instructions (5)
**
⚙️ CodeRabbit configuration file
**: # DSC Community GuidelinesTerminology
- Command: Public command
- Function: Private function
- Resource: DSC class-based resource
Build & Test Workflow Requirements
- Run PowerShell script files from repository root
- Setup build and test environment (once per
pwshsession):./build.ps1 -Tasks noop- Build project before running tests:
./build.ps1 -Tasks build- Always run tests in new
pwshsession:Invoke-Pester -Path @({test paths}) -Output DetailedFile Organization
- Public commands:
source/Public/{CommandName}.ps1- Private functions:
source/Private/{FunctionName}.ps1- Unit tests:
tests/Unit/{Classes|Public|Private}/{Name}.Tests.ps1- Integration tests:
tests/Integration/Commands/{CommandName}.Integration.Tests.ps1Requirements
- Follow instructions over existing code patterns
- Follow PowerShell style and test guideline instructions strictly
- Always update CHANGELOG.md Unreleased section
- Localize all strings using string keys; remove any orphaned string keys
- Check DscResource.Common before creating private functions
- Separate reusable logic into private functions
- DSC resources should always be created as class-based resources
- Add unit tests for all commands/functions/resources
- Add integration tests for all public commands and resources
Files:
CHANGELOG.mdsource/en-US/DscResource.DocGenerator.strings.psd1source/Public/Publish-WikiContent.ps1
**/*.md
⚙️ CodeRabbit configuration file
**/*.md: # Markdown Style Guidelines
- Wrap lines at word boundaries when over 80 characters (except tables/code blocks)
- Use 2 spaces for indentation
- Use '1.' for all items in ordered lists (1/1/1 numbering style)
- Disable
MD013rule by adding a comment for tables/code blocks exceeding 80 characters- Empty lines required before/after code blocks and headings (except before line 1)
- Escape backslashes in file paths only (not in code blocks)
- Code blocks must specify language identifiers
Text Formatting
- Parameters: bold
- Values/literals:
inline code- Resource/module/product names: italic
- Commands/files/paths:
inline code
Files:
CHANGELOG.md
CHANGELOG.md
⚙️ CodeRabbit configuration file
CHANGELOG.md: # Changelog Guidelines
- Always update the Unreleased section in CHANGELOG.md
- Use Keep a Changelog format
- Describe notable changes briefly, ≤2 items per change type
- Reference issues using format issue #<issue_number>
- No empty lines between list items in same section
- Skip adding entry if same change already exists in Unreleased section
- No duplicate sections or items in Unreleased section
Files:
CHANGELOG.md
{**/*.ps1,**/*.psm1,**/*.psd1}
⚙️ CodeRabbit configuration file
{**/*.ps1,**/*.psm1,**/*.psd1}: # PowerShell GuidelinesNaming
- Use descriptive names (3+ characters, no abbreviations)
- Functions: PascalCase with Verb-Noun format using approved verbs
- Parameters: PascalCase
- Variables: camelCase
- Keywords: lower-case
- Classes: PascalCase
- Include scope for script/global/environment variables:
$script:,$global:,$env:File naming
- Class files:
###.ClassName.ps1format (e.g.001.SqlReason.ps1,004.StartupParameters.ps1)Formatting
Indentation & Spacing
- Use 4 spaces (no tabs)
- One space around operators:
$a = 1 + 2- One space between type and variable:
[String] $name- One space between keyword and parenthesis:
if ($condition)- No spaces on empty lines
- Try to limit lines to 120 characters
Braces
- Newline before opening brace (except variable assignments)
- One newline after opening brace
- Two newlines after closing brace (one if followed by another brace or continuation)
Quotes
- Use single quotes unless variable expansion is needed:
'text'vs"text $variable"Arrays
- Single line:
@('one', 'two', 'three')- Multi-line: each element on separate line with proper indentation
- Do not use the unary comma operator (
,) in return statements to force
an arrayHashtables
- Empty:
@{}- Each property on separate line with proper indentation
- Properties: Use PascalCase
Comments
- Single line:
# Comment(capitalized, on own line)- Multi-line:
<# Comment #>format (opening and closing brackets on own line), and indent text- No commented-out code
Comment-based help
- Always add comment-based help to all functions and scripts
- Comment-based help: SYNOPSIS, DESCRIPTION (40+ chars), PARAMETER, EXAMPLE sections before function/class
- Comment-based help indentation: keywords 4 spaces, text 8 spaces
- Include examples for all parameter sets and combinations
- INPUTS: List each pipeline‑accepted type (one per line) with a 1‑line description...
Files:
source/en-US/DscResource.DocGenerator.strings.psd1source/Public/Publish-WikiContent.ps1
source/**/*.ps1
⚙️ CodeRabbit configuration file
source/**/*.ps1: # Localization GuidelinesRequirements
- Localize all Write-Debug, Write-Verbose, Write-Error, Write-Warning and $PSCmdlet.ThrowTerminatingError() messages
- Use localized string keys, not hardcoded strings
- Assume
$script:localizedDatais availableString Files
- Commands/functions:
source/en-US/{MyModuleName}.strings.psd1- Class resources:
source/en-US/{ResourceClassName}.strings.psd1Key Naming Patterns
- Format:
Verb_FunctionName_Action(underscore separators), e.g.Get_Database_ConnectingToDatabaseString Format
ConvertFrom-StringData @' KeyName = Message with {0} placeholder. (PREFIX0001) '@String IDs
- Format:
(PREFIX####)- PREFIX: First letter of each word in class or function name (SqlSetup → SS, Get-SqlDscDatabase → GSDD)
- Number: Sequential from 0001
Usage
Write-Verbose -Message ($script:localizedData.KeyName -f $value1)
Files:
source/Public/Publish-WikiContent.ps1
🧠 Learnings (10)
📚 Learning: 2025-09-16T16:35:31.909Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines.instructions.md:0-0
Timestamp: 2025-09-16T16:35:31.909Z
Learning: Applies to CHANGELOG.md : Always update the Unreleased section of CHANGELOG.md
Applied to files:
CHANGELOG.md
📚 Learning: 2025-09-14T19:17:05.477Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-changelog.instructions.md:0-0
Timestamp: 2025-09-14T19:17:05.477Z
Learning: Applies to CHANGELOG.md : Always update the Unreleased section in CHANGELOG.md
Applied to files:
CHANGELOG.md
📚 Learning: 2025-09-14T19:17:05.477Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-changelog.instructions.md:0-0
Timestamp: 2025-09-14T19:17:05.477Z
Learning: Applies to CHANGELOG.md : Describe notable changes briefly, with no more than 2 items per change type
Applied to files:
CHANGELOG.md
📚 Learning: 2025-09-14T19:17:05.477Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-changelog.instructions.md:0-0
Timestamp: 2025-09-14T19:17:05.477Z
Learning: Applies to CHANGELOG.md : No duplicate sections or items in the Unreleased section
Applied to files:
CHANGELOG.md
📚 Learning: 2025-09-14T19:17:05.477Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-changelog.instructions.md:0-0
Timestamp: 2025-09-14T19:17:05.477Z
Learning: Applies to CHANGELOG.md : Skip adding an entry if the same change already exists in the Unreleased section
Applied to files:
CHANGELOG.md
📚 Learning: 2025-09-14T19:17:05.477Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-changelog.instructions.md:0-0
Timestamp: 2025-09-14T19:17:05.477Z
Learning: Applies to CHANGELOG.md : Use Keep a Changelog format
Applied to files:
CHANGELOG.md
📚 Learning: 2025-08-29T17:22:23.268Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-localization.instructions.md:0-0
Timestamp: 2025-08-29T17:22:23.268Z
Learning: Applies to source/en-US/*.strings.psd1 : Define strings using ConvertFrom-StringData with entries like `KeyName = Message with {0} placeholder. (PREFIX0001)`
Applied to files:
source/en-US/DscResource.DocGenerator.strings.psd1
📚 Learning: 2025-09-12T13:20:57.155Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-mof-resources.instructions.md:0-0
Timestamp: 2025-09-12T13:20:57.155Z
Learning: Applies to source/DSCResources/**/*.psm1 : Use localized strings for all messages (e.g., Write-Verbose, Write-Error)
Applied to files:
source/en-US/DscResource.DocGenerator.strings.psd1
📚 Learning: 2025-08-29T17:22:23.268Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-localization.instructions.md:0-0
Timestamp: 2025-08-29T17:22:23.268Z
Learning: Applies to source/**/*.ps1 : Use localized string keys instead of hardcoded strings in script output/messages
Applied to files:
source/en-US/DscResource.DocGenerator.strings.psd1
📚 Learning: 2025-09-12T13:20:57.155Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-mof-resources.instructions.md:0-0
Timestamp: 2025-09-12T13:20:57.155Z
Learning: Applies to source/DSCResources/**/*.psm1 : Import localized strings at the top of the module using Get-LocalizedData
Applied to files:
source/en-US/DscResource.DocGenerator.strings.psd1
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (8)
- GitHub Check: dsccommunity.DscResource.DocGenerator (Test Publish Code Coverage)
- GitHub Check: dsccommunity.DscResource.DocGenerator (Test Unit macOS)
- GitHub Check: dsccommunity.DscResource.DocGenerator (Test Integration)
- GitHub Check: dsccommunity.DscResource.DocGenerator (Test Unit Linux)
- GitHub Check: dsccommunity.DscResource.DocGenerator (Test HQRM)
- GitHub Check: dsccommunity.DscResource.DocGenerator (Test Unit Windows (WPS))
- GitHub Check: dsccommunity.DscResource.DocGenerator (Test Unit Windows (PS))
- GitHub Check: dsccommunity.DscResource.DocGenerator (Build Package Module)
| Write-Verbose -Message $script:localizedData.AddWikiContentToGitRepoMessage | ||
|
|
||
| Invoke-Git -WorkingDirectory $tempPath -Arguments @( 'add', '*' ) | ||
| $gitAddResult = Invoke-Git -WorkingDirectory $tempPath -Arguments @( 'add', '*' ) -PassThru | ||
|
|
||
| Write-Verbose -Message ($script:localizedData.CommitAndTagRepoChangesMessage -f $ModuleVersion) | ||
| if ($gitAddResult.ExitCode -eq 1) | ||
| { | ||
| Write-Verbose -Message $script:localizedData.GitAddFailedMessage | ||
| } | ||
| else | ||
| { | ||
| Write-Verbose -Message ($script:localizedData.CommitAndTagRepoChangesMessage -f $ModuleVersion) | ||
|
|
||
| Invoke-Git -WorkingDirectory $tempPath ` | ||
| -Arguments @( 'commit', '--message', "`"$($script:localizedData.UpdateWikiCommitMessage -f $ModuleVersion)`"" ) | ||
| Invoke-Git -WorkingDirectory $tempPath ` | ||
| -Arguments @( 'commit', '--message', "`"$($script:localizedData.UpdateWikiCommitMessage -f $ModuleVersion)`"" ) | ||
|
|
||
| Write-Verbose -Message $script:localizedData.PushUpdatedRepoMessage | ||
| Write-Verbose -Message $script:localizedData.PushUpdatedRepoMessage | ||
|
|
||
| Invoke-Git -WorkingDirectory $tempPath ` | ||
| -Arguments @( 'tag', '--annotate', $ModuleVersion, '--message', $ModuleVersion ) | ||
| Invoke-Git -WorkingDirectory $tempPath ` | ||
| -Arguments @( 'tag', '--annotate', $ModuleVersion, '--message', $ModuleVersion ) | ||
|
|
||
| Invoke-Git -WorkingDirectory $tempPath -Arguments @( 'push', 'origin' ) | ||
| Invoke-Git -WorkingDirectory $tempPath -Arguments @( 'push', 'origin' ) | ||
|
|
||
| Invoke-Git -WorkingDirectory $tempPath -Arguments @( 'push', 'origin', $ModuleVersion ) | ||
| Invoke-Git -WorkingDirectory $tempPath -Arguments @( 'push', 'origin', $ModuleVersion ) | ||
|
|
||
| Write-Verbose -Message $script:localizedData.PublishWikiContentCompleteMessage | ||
| Write-Verbose -Message $script:localizedData.PublishWikiContentCompleteMessage | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
Git add guard has correctness gaps and doesn’t yet fix the “nothing to commit” failure from issue #172
A few points on this new block:
-
Exit code check is too narrow
if ($gitAddResult.ExitCode -eq 1) { Write-Verbose -Message $script:localizedData.GitAddFailedMessage } else { # commit / tag / push }
- Any non‑zero exit code other than
1will be treated as “success” and still run commit/tag/push, even thoughgit addactually failed. - You almost certainly want to treat any non‑zero exit code as failure:
if ($gitAddResult.ExitCode -ne 0) { # handle failure }
- Any non‑zero exit code other than
-
Real git‑add failures are silently downgraded to verbose
- In the failure branch you only emit
Write-Verbose. With default settings this is invisible, while the comment/message says “Wiki will not be updated”. - For an actual git error, callers likely expect the command to clearly fail (e.g., via
Write-Erroror a terminating error), not just silently skip the publish.
- In the failure branch you only emit
-
Issue Publishing Wiki content fails if there’s nothing to commit #172 (“nothing to commit, working tree clean”) is not addressed
- The reported problem is that
git commitreturns a non‑zero exit code when there’s nothing to commit, causingPublish-WikiContentto fail. git add *still exits0when there are no changes, so this guard does not prevent thegit commitinvocation from running in that scenario.Invoke-Gitis still called forcommitwithout-PassThru, so ifgit commitreturns1with “nothing to commit, working tree clean”, it will still throw and fail the build as before.
To truly fix Publishing Wiki content fails if there’s nothing to commit #172 you need to short‑circuit before commit/tag/push when there are no staged changes, for example by using
git status --porcelainwith-PassThruand the existingNothingToCommitToWikilocalized message. - The reported problem is that
-
Suggested direction
Consider something along these lines:
- $gitAddResult = Invoke-Git -WorkingDirectory $tempPath -Arguments @( 'add', '*' ) -PassThru - - if ($gitAddResult.ExitCode -eq 1) - { - Write-Verbose -Message $script:localizedData.GitAddFailedMessage - } - else - { + $gitAddResult = Invoke-Git -WorkingDirectory $tempPath -Arguments @( 'add', '*' ) -PassThru + + if ($gitAddResult.ExitCode -ne 0) + { + Write-Error -Message $script:localizedData.GitAddFailedMessage ` + -Category InvalidOperation ` + -ErrorId 'PublishWikiContent_GitAddFailed' ` + -TargetObject $tempPath + + return + } + + # No staged changes => nothing to commit; exit gracefully. + $gitStatusResult = Invoke-Git -WorkingDirectory $tempPath -Arguments @( 'status', '--porcelain' ) -PassThru + + if ([string]::IsNullOrWhiteSpace($gitStatusResult.StandardOutput)) + { + Write-Verbose -Message $script:localizedData.NothingToCommitToWiki + return + } + + { Write-Verbose -Message ($script:localizedData.CommitAndTagRepoChangesMessage -f $ModuleVersion) Invoke-Git -WorkingDirectory $tempPath ` -Arguments @( 'commit', '--message', "`"$($script:localizedData.UpdateWikiCommitMessage -f $ModuleVersion)`"" ) Write-Verbose -Message $script:localizedData.PushUpdatedRepoMessage Invoke-Git -WorkingDirectory $tempPath ` -Arguments @( 'tag', '--annotate', $ModuleVersion, '--message', $ModuleVersion ) Invoke-Git -WorkingDirectory $tempPath -Arguments @( 'push', 'origin' ) Invoke-Git -WorkingDirectory $tempPath -Arguments @( 'push', 'origin', $ModuleVersion ) Write-Verbose -Message $script:localizedData.PublishWikiContentCompleteMessage }
This way:
- Any git‑add failure is clearly surfaced as an error.
- The “nothing to commit” case short‑circuits cleanly and should no longer fail the publishing process, aligning with Publishing Wiki content fails if there’s nothing to commit #172.
- Real commit/tag/push errors still bubble up as before.
Please re‑run the scenario from issue #172 (no changes in the wiki repo) with this function to confirm that Publish-WikiContent no longer fails when there is nothing to commit, and that genuine git errors are still visible to callers.
I'll help you verify this review comment. Let me gather the necessary information by examining the codebase.
Now let me examine the actual codebase:
Now let me examine the actual file and verify the code exists:
🏁 Script executed:
#!/bin/bash
# Check if file exists and examine lines 167-192
if [ -f "source/Public/Publish-WikiContent.ps1" ]; then
echo "=== Lines 167-192 from Publish-WikiContent.ps1 ==="
sed -n '167,192p' "source/Public/Publish-WikiContent.ps1"
else
echo "File not found: source/Public/Publish-WikiContent.ps1"
find . -name "Publish-WikiContent.ps1" -type f 2>/dev/null | head -5
fiLength of output: 1233
🏁 Script executed:
#!/bin/bash
# Find and examine Invoke-Git implementation
echo "=== Searching for Invoke-Git function definition ==="
rg -nA 30 'function Invoke-Git' --type ps1 -B 2 | head -80Length of output: 80
🏁 Script executed:
#!/bin/bash
# Check for localized string key definitions
echo "=== Searching for localized string keys ==="
rg -nA 2 'GitAddFailedMessage|NothingToCommitToWiki' --type psd1 | head -40Length of output: 72
Let me continue verification with corrected search commands:
Now let me search for the Invoke-Git function and localized strings in the codebase:
🏁 Script executed:
#!/bin/bash
# Find Invoke-Git function without type filter
echo "=== Searching for Invoke-Git function definition ==="
rg -nA 15 'function Invoke-Git' --context=3 | head -100Length of output: 477
🏁 Script executed:
#!/bin/bash
# Check for localized string key definitions (no type filter)
echo "=== Searching for localized string keys ==="
rg -n 'GitAddFailedMessage|NothingToCommitToWiki' --context=2 | head -60Length of output: 2729
🏁 Script executed:
#!/bin/bash
# Look for strings.psd1 files to understand where keys are defined
echo "=== Locating strings.psd1 files ==="
find . -name "*.strings.psd1" -type f 2>/dev/null | head -20Length of output: 88
Now let me examine the Invoke-Git implementation more closely to understand -PassThru behavior:
🏁 Script executed:
#!/bin/bash
# Get full Invoke-Git function implementation
echo "=== Full Invoke-Git function ==="
sed -n '32,120p' source/Public/Invoke-Git.ps1Length of output: 2981
🏁 Script executed:
#!/bin/bash
# Check Out-GitResult to understand error handling
echo "=== Out-GitResult function start ==="
sed -n '1,100p' source/Private/Out-GitResult.ps1Length of output: 2778
🏁 Script executed:
#!/bin/bash
# Check how commit/tag/push are called (without -PassThru)
echo "=== Checking Invoke-Git calls in Publish-WikiContent ==="
rg -n 'Invoke-Git' source/Public/Publish-WikiContent.ps1 -B1 -A1 | head -60Length of output: 1537
Exit code check is too narrow and doesn't prevent the "nothing to commit" failure from issue #172
The new code introduces several issues:
-
Exit code check only catches
1, not all failuresThe condition
if ($gitAddResult.ExitCode -eq 1)catches only exit code 1, but any other non-zero exit code fromgit addis silently treated as success and continues to the commit/tag/push block. This should be:if ($gitAddResult.ExitCode -ne 0)
-
Real git-add errors are only logged verbosely
When
git addfails with exit code 1, onlyWrite-Verboseis called. Since verbose output is disabled by default, actual git errors are invisible to callers. Error-level output should be used to surface real failures. -
The "nothing to commit" failure (Publishing Wiki content fails if there’s nothing to commit #172) is not prevented
The core issue remains unsolved:
git add *exits with code 0 even when there are no changes, so this guard doesn't short-circuit beforegit commit. Whengit commitruns and finds nothing to commit, it exits with code 1. Sincecommitis called without-PassThru,Invoke-Gitthrows, causing the function to fail—the exact Publishing Wiki content fails if there’s nothing to commit #172 problem.To fix this, detect when there are no staged changes before attempting commit. Use
git status --porcelainwith-PassThruand short-circuit gracefully:$gitStatusResult = Invoke-Git -WorkingDirectory $tempPath -Arguments @( 'status', '--porcelain' ) -PassThru if ([string]::IsNullOrWhiteSpace($gitStatusResult.StandardOutput)) { Write-Verbose -Message $script:localizedData.NothingToCommitToWiki return }
🤖 Prompt for AI Agents
In source/Public/Publish-WikiContent.ps1 around lines 167-192, the git-add
handling is too narrow and doesn't prevent the "nothing to commit" failure:
change the exit-code check to treat any non-zero as failure (use -ne 0) and log
real git-add failures with an error-level call rather than Write-Verbose; after
git add run git status --porcelain with -PassThru and if its StandardOutput is
empty write the localized "NothingToCommitToWiki" message and return early to
avoid running commit/tag/push; also invoke commit (and other critical git
commands) with -PassThru and verify their ExitCode so failures are handled
explicitly rather than letting Invoke-Git throw unobserved.
1 participant
Pull Request (PR) description
Only run the other git commands if git add was successful.
This Pull Request (PR) fixes the following issues
Task list
Entry should say what was changed and how that affects users (if applicable), and
reference the issue being resolved (if applicable).
This change is