DAT-20906 DevOps :: Create Automated Release Workflow for Liquibase Secure Extensions (BigQuery, Databricks, MongoDB, Azure, AWS)

[jandroav]

This pull request improves the robustness of the automated release workflow for extensions by enhancing error handling and logging during the Dependabot update process. The main focus is to ensure that known authentication failures with private dependencies do not cause the workflow to fail, while still surfacing unexpected errors.

Dependabot update workflow improvements:

• Enhanced the Dependabot update step in .github/workflows/extension-automated-release.yml to capture output and exit codes, allowing for more granular error handling and improved logging.
• Implemented logic to detect and tolerate known authentication failures for specific private dependencies (e.g., com.simba.googlebigquery.jdbc:GoogleBigQueryJDBC42, com.liquibase:liquibase-extension-testing), allowing the workflow to continue if only these are affected, and providing clear warnings to update them manually if needed.
• Removed the unused repositories parameter from the app-id step, likely as part of workflow simplification.

Summary by CodeRabbit

• Chores
  • Improved the automated release workflow to handle dependency updates more robustly, gracefully skipping known authentication failures while continuing with remaining updates.

[coderabbitai]

Walkthrough

This change enhances the extension automated release workflow by replacing a simple dependabot update step with a resilient multi-step approach. The new logic captures command output and exit codes, distinguishes between known authentication failures for private dependencies and critical errors, logs appropriate warnings for known failures, and continues execution while maintaining existing success logging.

Changes

Cohort / File(s)	Summary
GitHub Actions Workflow Error Handling \.github/workflows/extension-automated-release\.yml	Removed matrix.repository input forwarding from token acquisition step. Replaced inline dependabot update command with guarded multi-step execution: captures output and exit code, inspects for successful updates, detects known authentication failure patterns in private dependencies, logs warnings for known failures while continuing, fails on other errors, and preserves success logging.

Sequence Diagram

sequenceDiagram
    participant WF as Workflow
    participant Dependabot
    participant Logger
    
    WF->>Dependabot: Execute update command (capture output)
    Dependabot-->>WF: Returns exit code + output
    
    alt Exit Code = 0
        WF->>Logger: Log successful completion
        Logger-->>WF: ✓
    else Exit Code ≠ 0
        WF->>WF: Inspect output for successful updates
        
        alt Updates Found
            WF->>WF: Check for known auth failure patterns
            
            alt Only Known Failures
                WF->>Logger: Log warnings (skip problematic deps)
                Logger-->>WF: Continue execution
            else Other Errors Present
                WF->>WF: Fail step with original exit code
            end
        else No Updates Found
            WF->>WF: Fail step with original exit code
        end
    end
    
    WF->>Logger: Preserve existing success logging
    Logger-->>WF: ✓

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~15 minutes

• Focus areas:
  • Validation of error detection logic and patterns used to identify known authentication failures
  • Verification that the multi-step conditional flow correctly handles all edge cases (success, known failures, unknown errors)
  • Confirmation that output capture and exit code handling preserves workflow state correctly
  • Review of logging statements to ensure appropriate detail level for troubleshooting

Suggested reviewers

• jnewton03

Poem

🐰 A workflow grows wise, with care in its veins,
Now handling failures and private domain pains,
When auth ghosts appear, it logs and proceeds,
While catching true errors—exactly what's needed!
Dependabot dances with grace, never stumbling,
The release pipeline hums, no more grumbling! 🚀

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Linked Issues check	⚠️ Warning	The PR only implements error handling improvements to the Dependabot step in an existing workflow, not the full automated release workflow creation required by DAT-20906.	Complete the implementation of the main release workflows for BigQuery, Databricks, MongoDB, Azure, and AWS extensions as specified in the linked issue acceptance criteria.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The PR title accurately reflects the main objective: creating automated release workflows for Liquibase Secure Extensions.
Out of Scope Changes check	✅ Passed	All changes are focused on improving robustness of the Dependabot step and removing unused parameters in the existing extension-automated-release workflow, which are in scope for workflow refinement.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch DAT-20906-test

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

.github/workflows/extension-automated-release.yml (2)

130-158: Consider more robust output parsing for Dependabot error detection.

The error-handling logic relies on grep patterns to detect successful updates ("Changes to Dependabot Pull Requests") and known authentication failures. This approach is fragile and could break if Dependabot's output format changes.

Specific concerns:

1. Line 139: The "Changes to Dependabot Pull Requests" string may not reliably indicate success across all Dependabot versions and configurations.

2. Line 143: The regex .*private_source_authentication_failure assumes the error pattern appears on the same line as (or immediately after) the dependency name. If Dependabot's output format uses multi-line errors or different spacing, this pattern could fail to match or incorrectly match unrelated failures.

3. Fragility: Any changes to Dependabot's output format could cause silent failures or false positives.

Suggestions for improvement:

• Consider parsing Dependabot's structured output or exit codes if available, rather than text pattern matching.
• Add inline comments documenting the expected output format and which Dependabot version(s) this was validated against.
• Consider capturing a sample of Dependabot output (sanitized) for debugging if the step fails in production.

Can you verify that these regex patterns match actual Dependabot CLI output for the versions you're using? If possible, consider creating a test matrix or documentation showing example output.

---

137-158: Document the success condition edge case.

The logic treats an exit code of 0 as success (line 158) without checking whether the output contains known failures. This could mask issues where Dependabot partially succeeds but also encounters known private dependency authentication failures.

If this is intentional (i.e., Dependabot returns 0 on partial success), add a comment explaining this behavior. Otherwise, consider whether the known-failures check should also apply when exit code is 0.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Jira integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 534f7b7 and 9e1988a.

📒 Files selected for processing (1)

• .github/workflows/extension-automated-release.yml (1 hunks)

🔇 Additional comments (2)

.github/workflows/extension-automated-release.yml (2)

102-108: Verify consistency of repositories parameter removal across get-token steps.

The repositories parameter has been removed from the get-token step in run-extensions-dependabot (lines 102-108), but it remains in other jobs (update-pom at line 190 and release-draft-releases at line 302). This inconsistency should either be intentional or normalized.

If intentional, document why this step alone doesn't need the repositories restriction. If not, consider whether removing it affects the security posture (least-privilege principle) or token access scope.

---

130-135: Output capturing approach is sound.

The use of set +e / set -e to capture both exit code and output (lines 130-135) is the correct pattern. Echoing the output immediately (line 135) maintains good observability for debugging workflow failures.