ci: skip integration tests on Dependabot branches - #676
Open
NickJosevski wants to merge 1 commit into
Open
Conversation
All three Dependabot PRs opened since #630 (#671, #672, #673) fail this workflow at "Initialize containers", and none of them fail for a reason related to the dependency being bumped. GitHub scopes secrets for Dependabot-triggered runs to a separate Dependabot secrets store, so DB_IMAGE_SA_PASSWORD, OD_IMAGE_ADMIN_API_KEY and OCTOPUS_SERVER_BASE64_LICENSE all resolve to empty. The log shows it unmasked, where a real secret would print as ***: -e "DB_CONNECTION_STRING=Server=sqlserver;...;User Id=sa;Password=;" SQL Server then rejects every login ("Login failed for user 'sa'. Reason: An error occurred while evaluating the password"), the health check never passes, the service container is marked unhealthy and the job dies before any test runs. Every dependabot/* branch fails; every human branch, main, release-please and the nightly schedule pass. Skipping is preferred over supplying the secrets. Copying them into the Dependabot store would hand an Octopus license and a test API key to a run whose dependency tree just changed and which executes third-party code via go test, and it still would not go green, because dorny/test-reporter needs checks: write and the Dependabot token stays read-only regardless of the permissions block. Coverage is retained: the nightly run on main picks up merged bumps within a day, and workflow_dispatch still works on a Dependabot branch since the triggering actor is then a human -- gh workflow run integration-test.yml --ref dependabot/go_modules/... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the red X on every Dependabot PR opened since #630 (#671, #672, #673). One line plus a comment.
Why they fail
Not the dependency bumps. GitHub scopes secrets for Dependabot-triggered runs to a separate Dependabot secrets store, so
DB_IMAGE_SA_PASSWORD,OD_IMAGE_ADMIN_API_KEYandOCTOPUS_SERVER_BASE64_LICENSEall resolve to empty strings. The log shows it unmasked — a real secret would print as***:SQL Server rejects every login (
Login failed for user 'sa'. Reason: An error occurred while evaluating the password), the health check never passes, the container is markedunhealthy, and the job dies at Initialize containers before a single test runs.The split is clean:
dependabot/go_modules/...cobra-1.10.2dependabot/go_modules/...go-octopusdeploy-2.114.1dependabot/go_modules/...doublestar-4.10.0main,release-please--*, nightlyscheduleThis is a latent incompatibility in this workflow that enabling Dependabot in #630 exposed, not a regression in it.
Why skip rather than supply the secrets
Copying those three into the Dependabot store would start the containers, but it hands an Octopus license and a test API key to a run whose dependency tree just changed and which executes third-party code via
go test. It also still wouldn't go green —dorny/test-reporterneedschecks: write, and the DependabotGITHUB_TOKENstays read-only no matter what thepermissions:block says.Coverage is retained
main(5am Brisbane, currently passing) picks up any merged bump within a day.workflow_dispatchstill works on a Dependabot branch, because the triggering actor is then a human and secrets resolve normally:I've kicked exactly that off against #672 —
go-octopusdeployis the client library these tests actually exercise, so it's the one bump where the coverage genuinely matters. Result linked in that PR.if: github.actor != 'dependabot[bot]'at the job level makes the check skipped rather than failed, so it stays visible as not-run instead of reading as a broken build. Manual dispatch is unaffected by the condition sincegithub.actoris the dispatcher.Note
maincurrently has no required status checks, so these failures were noise rather than a merge gate — but noise that trains people to ignore a red X on dependency PRs is worth removing.🤖 Generated with Claude Code