Adding archiver for Azure blob store

[uromahn]

This implementation has been mostly generated by a coding agent (Google Antigravity) with a few minor exceptions.
All generated code has been thoroughly reviewed and tested.

What changed?

I have added a new archiver implementation using Azure blob storage.

Why?

Currently, there are only three archiver available:

1. filestore (not really scalable and usable in an enterprise environment)
2. AWS S3 store
3. GCP cloud storage

However, there are a large number of enterprise customers that are running their workloads in Azure and
would like to use Azure blob store for their self-hosted deployment there.

How did you test it?

• built
• run locally and tested manually
• covered by existing tests
• added new unit test(s)
• added new functional test(s)
• integration tested locally and an Azure storage account

Potential risks

None

The archiver is completely isolated and decoupled from the core functionality. Even if there is a bug in the Azure archiver implementation, core functionality will not be impacted and keeps running, albeit without archiving.

Potential future improvement

Add automated integration tests using the Azurite container locally.

[CLAassistant]

All committers have signed the CLA.

[yycptt]

Hi @uromahn,

Thank you for the contribution and for your interest in improving Temporal — we really appreciate the effort.

Unfortunate, at the moment, the team doesn’t have the bandwidth to take on and maintain an additional archiver implementation in this repository. To ensure we can properly support and maintain what’s in-tree, we need to be selective about adding new long-term maintenance surface area.

That said, we’re working on enabling custom archiver implementations to be injected via ServerOptions (see https://github.com/temporalio/temporal/pull/9090/changes
). Once that’s available, it should make it much easier to support alternative implementations outside of the main repo.

Thanks again for the contribution and for being part of the community 🙏

[uromahn]

This is a bit disappointing!
While I understand the argument and can follow it, I don't believe adding this code would have added much additional maintenance burden. Based on the file history, all the archiver implementation had very little "maintenance" (less than 10 commits per file in the archiver package). And the fact that the existing gcloud implementation had such a long-standing bug, is another sign that there does not seem to be any interest in maintaining any of the archiver code.

Anyways, I am looking forward to the ServerOptions implementation so I can then simply "inject" the Azure archiver.
I will take a closer look at your PR and how this is supposed to work.

In the meantime, I will close my PR without merging. In case you change your mind and consider adding the Azure archiver, feel free to email me and I am happy to update my code and re-submit a new PR.