feat(azblob): add azure blob storage provider by Jonas-Beck · Pull Request #257 · falcondev-oss/github-actions-cache-server

Jonas-Beck · 2026-08-04T06:45:56Z

This PR adds support for using azure blob storage as a storage provider

This has support for authentication using connection string and also authentication using the @azure/identity package DefaultAzureCredentials

Part of #256

helmchart has also been updated to support configuring the new env variables for azblob storage driver, currently any authentication related configuration when using DefaultAzureCredentials are not exposed in the storage.azblob values.

This means that for anyone using workload identity to authenticate, annotations should be added to the ServiceAccount using serviceAccount.annotations and labels on the pods should added using podLabels

Signed-off-by: Jonas Beck <dev@jonasbeck.dk>

LouisHaftmann

Sorry for leaving this without a response for so long, I couldn't find the time to look at it properly. Thanks for your patience, and for the PR. The adapter fits well with the existing ones.

I checked out the branch and ran it against Azurite. Four things need fixing before merge. Numbers 1, 2 and 4 are bugs, and 3 is the missing test that would have caught 1 and 2. The rest are smaller.

With a connection string, createDownloadUrl throws Server failed to authenticate the request when ENABLE_DIRECT_DOWNLOADS is on.
The download URL always uses https://{account}.blob.core.windows.net, even when the server is configured with a different endpoint.
No test calls createDownloadUrl for azblob, so CI passes without covering 1 and 2.
deleteFolder('abc') also deletes abc123/....

Details are in the inline comments.

LouisHaftmann · 2026-09-13T11:16:56Z

+    const startsOn = new Date()
+    const expiresOn = new Date(expiresAt)
+
+    const delegationKey = await this.client.getUserDelegationKey(startsOn, expiresOn)


It looks like getUserDelegationKey only works with Entra ID credentials, so with a connection string it fails:

Server failed to authenticate the request. Make sure the value of the Authorization header is formed correctly including the signature.

I tried blobClient.generateSasUrl() for the connection string case, and the URL it generated worked. Maybe use that there and keep the delegation key for DefaultAzureCredential?

Also, setting startsOn to exactly now can cause 403s if the clocks are slightly off. It's probably safer to leave it out or set it a few minutes back.

LouisHaftmann · 2026-09-13T11:17:38Z

+      this.account,
+    )
+
+    return `https://${this.account}.blob.core.windows.net/${this.container}/${this.blobKey(objectName)}?${sasParams.toString()}`


This one ignores STORAGE_AZBLOB_ENDPOINT and the endpoint from the connection string. On Azurite I got https://devstoreaccount1.blob.core.windows.net/... back, but the blob actually lives at http://localhost:10000/devstoreaccount1/.... Building the URL from getBlobClient(key).url should fix it.

LouisHaftmann · 2026-09-13T11:18:43Z

+  async deleteFolder(folderName: string): Promise<StorageDeletion> {
+    const deleted = { objects: 0, bytes: 0 }
+    const blobs = this.containerClient.listBlobsFlat({
+      prefix: this.blobKey(folderName),


I think the prefix needs a trailing slash here. Without it, other folders that start with the same name match too:

await adapter.uploadStream('abc/merged', ...) await adapter.uploadStream('abc123/merged', ...) await adapter.deleteFolder('abc') // { objects: 2, bytes: 2 } await adapter.objectExists('abc123/merged') // false

S3 and GCS use ${keyPrefix}/${folderName}/. countFilesInFolder and getFolderSize have the same issue.

The prefix has been updated to include trailing slash for deleteFolder / countFilesInFolder / getFolderSize. I have also added test case for this, that is run on all storage providers.

LouisHaftmann · 2026-09-13T11:19:20Z

+    for await (const blob of blobs) {
+      deleted.objects++
+      deleted.bytes += blob.properties.contentLength ?? 0
+      await this.containerClient.deleteBlob(blob.name)


This deletes blobs one request at a time, which gets slow for entries with lots of parts. BlobBatchClient.deleteBlobs can do up to 256 per request, and the same would help in clear().

I have updated it to make use of BlobBatchClient for bulk deletion of blobs.

It will use the max request limit(256) as the page size when listing blobs and then perform batch deletion for each page.

LouisHaftmann · 2026-09-13T11:20:04Z

  },
+  {
+    'STORAGE_DRIVER': type.unit('azblob'),
+    'STORAGE_AZBLOB_ACCOUNT': 'string',


Since the connection string already includes the account name, it'd be nice not to require STORAGE_AZBLOB_ACCOUNT as well. Maybe split this into a connection string branch and an account + DefaultAzureCredential branch? The adapter can get the account name from client.accountName.

LouisHaftmann · 2026-09-13T11:20:53Z

+  value: {{ .container | quote }}
+{{- end }}
+{{- if .connectionString }}
+- name: STORAGE_AZBLOB_CONNECTION_STRING


This ends up putting the account key into the Deployment as plain text. What do you think about leaving connectionString out of values.yaml and pointing people to existingSecret instead?

Makes sense to me, should never really be configured directly in values. But from what I can see this is the pattern used by other secrets as well e.g db.postgres.password

For now I have removed connectionString from both values and helpers. Also mentioned the connection string as example for the existingSecret.

LouisHaftmann · 2026-09-13T11:21:23Z

+    const response = await blockBlobClient.download()
+    if (!response.readableStreamBody) throw new Error(`No stream for blob "${objectName}"`)
+    // Casting from NodeJS.ReadableStream to Readable
+    return response.readableStreamBody as Readable


Just a nit: Readable.from(response.readableStreamBody) would get rid of the cast.

I have removed the cast and use Readable.from now instead.

Signed-off-by: Jonas Beck <dev@jonasbeck.dk>

Jonas-Beck · 2026-09-16T10:40:29Z

Thanks for the review, I will get the PR updated

Signed-off-by: Jonas Beck <dev@jonasbeck.dk>

Jonas-Beck added 5 commits July 30, 2026 10:42

feat(azblob): add azure dependencies

e055b1c

Signed-off-by: Jonas Beck <dev@jonasbeck.dk>

feat(azblob): add initial implementation

d936010

Signed-off-by: Jonas Beck <dev@jonasbeck.dk>

feat(azblob): add listStorageFolders implementation

3936c99

Signed-off-by: Jonas Beck <dev@jonasbeck.dk>

feat(azblob): add rest of interface functions

a3bf7b6

Signed-off-by: Jonas Beck <dev@jonasbeck.dk>

test(azblob): implement test using azurite

396b3d4

Signed-off-by: Jonas Beck <dev@jonasbeck.dk>

Jonas-Beck mentioned this pull request Aug 4, 2026

Support Azure Blob Storage driver #256

Open

Jonas-Beck commented Aug 4, 2026

View reviewed changes

Comment thread lib/schemas.ts

Jonas-Beck marked this pull request as draft August 4, 2026 07:01

feat(chart): add azblob config values

de315e6

Signed-off-by: Jonas Beck <dev@jonasbeck.dk>

Jonas-Beck marked this pull request as ready for review August 4, 2026 10:23

DrJume linked an issue Aug 4, 2026 that may be closed by this pull request

Support Azure Blob Storage driver #256

Open

DrJume requested a review from LouisHaftmann August 4, 2026 17:38

LouisHaftmann reviewed Sep 13, 2026

View reviewed changes

chore(azblob): use Readable.from instead of casting

8c4d1e6

Signed-off-by: Jonas Beck <dev@jonasbeck.dk>

Jonas-Beck added 3 commits September 16, 2026 12:58

fix(azblob): add trailing slash to prefix

feefec7

Signed-off-by: Jonas Beck <dev@jonasbeck.dk>

chore(azblob): use BlobBatchClient for deletion of blobs

dec1b55

Signed-off-by: Jonas Beck <dev@jonasbeck.dk>

chore(azblob): remove connectionString from values and helpers

b64aa95

Signed-off-by: Jonas Beck <dev@jonasbeck.dk>

Jonas-Beck force-pushed the feature/azblob branch from 3264e68 to b64aa95 Compare September 16, 2026 12:13

Uh oh!

Conversation

Jonas-Beck commented Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

LouisHaftmann left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Jonas-Beck commented Sep 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Jonas-Beck commented Aug 4, 2026 •

edited

Loading