Skip to content

CI - Scope the Azure log shipping test databases by run id so concurrent runs do not share a blob name - #10717

Open
andreasjordan wants to merge 1 commit into
developmentfrom
fix-ci-azure-logship-run-unique-name
Open

andreasjordan wants to merge 1 commit into
developmentfrom
fix-ci-azure-logship-run-unique-name

Conversation

@andreasjordan

Copy link
Copy Markdown
Collaborator

Fixes #10667. Carries the .github/scripts/gh-actions.ps1 part of #10679 by @simonyang08, as proposed in the review there; the command change and the source-reading test file of that PR are left out.

The flake

On 2026-08-31 three PRs pushed within about 30 seconds ran "sets up log shipping to Azure blob storage using SAS token" at the same second. The test used the fixed database name dbatoolsci_logship_azure, and Invoke-DbaDbLogShipping names the blob <database>_FullBackup_PreLogShipping_<yyyyMMddHHmmss>.bak, so all three runs wrote to the same blob in the shared container. The run for #10665 lost:

The file https://dbatools.blob.core.windows.net/dbatools/dbatoolsci_logship_azure_FullBackup_PreLogShipping_20260831075712.bak
exists on the remote endpoint, and WITH FORMAT was not specified. Backup cannot proceed.

The change

Both Azure log shipping test database names (dbatoolsci_logship_azure and dbatoolsci_logship_addsecondary) now carry GITHUB_RUN_ID and GITHUB_RUN_ATTEMPT, for example dbatoolsci_logship_azure_31789177009_1. Every run and every rerun then works on its own database and its own blobs, whatever the timestamp says. The blob cleanup at the end of each test lists by the database name as prefix, so it keeps finding its own blobs; the derived names of the second test (_second, _missing) build on the scoped name and follow along. Nothing else in the repository uses the old literal names.

No command change: the collision is a property of the shared CI container and the fixed test name, not of the command, and a finer timestamp would also rename the on-premises backup file for every user.

What this does not do

The first test's cleanup sits after its assertions, without a finally. A run that fails before it now leaves its blobs behind under its own run id, where the next run's broad prefix used to sweep them. Sweeping the old broad prefix again would delete another concurrent run's backup while it restores, which is the same race from the other side, so the leftovers are the price of the fix and can be removed by hand from the container when it matters.

Verification

The script parses, and the name resolves to dbatoolsci_logship_azure_<run id>_<attempt> with the GitHub environment set. Run Cross Platform Tests triggers on the push of this branch with the real SAS token, so the Azure tests run on this PR's CI.

created by Claude and reviewed by Andreas Jordan

🤖 Generated with Claude Code

…ent runs do not share a blob name

Both Azure log shipping tests in gh-actions.ps1 used a fixed database name, and Invoke-DbaDbLogShipping builds the blob name from the database name and a timestamp with second resolution. Two runs on different branches that reached the backup within the same second fought over one blob in the shared container, and the loser failed with "exists on the remote endpoint, and WITH FORMAT was not specified" (#10667). The names now carry GITHUB_RUN_ID and GITHUB_RUN_ATTEMPT, so every run and rerun uses its own database and blobs. The blob cleanup lists by the database name as prefix, so it keeps finding its own blobs.

Carries the CI script part of #10679 by simonyang08.

(do Invoke-DbaDbLogShipping)

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CI: the Azure log shipping test collides across concurrent runs because its backup name is only second-unique

1 participant