docs: Rewrite Azure Batch tutorial for native Batch Forge support

[adamrtalbot]

Context

The manual-azure-batch-setup.md tutorials were written when advanced Azure Batch topologies required manual Nextflow config and manual Azure Portal pool creation. Seqera Platform now provisions most of these natively via Batch Forge and the compute-environment form.

Verified against seqera/platform:

Old tutorial option	Now native?
Batch Forge single pool	Forge now creates separate head/worker pools by default
Separate pools via process.queue	Native (Forge default)
Hot head node	Native (disable autoscale + Head VM type/CPUs/memory)
Nextflow autopool	Deprecated/disabled (allowPoolCreation=false)
Entra service principal + managed identity	Native (Entra credential + MI form fields)
VNet pool	Native (Subnet ID field, Entra-gated)
VNet + autopool workers	Native (subnet applied to worker pool by Forge)

Batch Forge provisions dedicated nodes only, so low-priority (spot) nodes remain a genuinely manual step and are preserved.

Changes

• Restructure both tutorials as a native-first Batch Forge walkthrough (Cloud + Enterprise latest).
• Keep genuinely manual content: low-priority (spot) worker nodes and pre-existing/custom pools.
• Remove the deprecated Nextflow autopool options; replace with a short deprecation note.
• Add reference cross-links from compute-envs/azure-batch.md to the tutorial (previously only linked one way).

Versioned snapshots (24.2–26.1) left untouched.

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for seqera-docs ready!

Name	Link
🔨 Latest commit	9c4f102
🔍 Latest deploy log	https://app.netlify.com/projects/seqera-docs/deploys/6a8700961f57310008e78f4a
😎 Deploy Preview	https://deploy-preview-1674--seqera-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[justinegeffen]

@claude please port this to the current versioned docs (26.1) as well

[claude]

Claude finished @justinegeffen's task in 2m 50s —— View job

---

Porting Azure Batch tutorial to versioned docs (26.1)

• Read the 26.1 versioned files and compare with the new master versions
• Port manual-azure-batch-setup.md to version-26.1
• Port azure-batch.md cross-link to version-26.1
• Verify relative links resolve in the versioned tree
• Commit and push — committed locally, but push denied (403)

---

I ported both changes to platform-enterprise_versioned_docs/version-26.1/, mirroring the master rewrite:

• enterprise/advanced-topics/manual-azure-batch-setup.md — full native-first Batch Forge rewrite (Parts 1–4 + Advanced), matching the enterprise-latest version. Verified the versioned cross-link anchors resolve (#entra-service-principal-and-managed-identity at line 150, #create-a-nextflow-compatible-azure-batch-pool at line 394). I kept the versioned file's existing install-seqera-cli reference (https://docs.seqera.io/platform-cli/installation) rather than the root-relative form used in the unversioned file, consistent with the snapshot's conventions.
• compute-envs/azure-batch.md — added the same :::tip cross-link to the walkthrough under Add compute environment.

Net: +60 / −328 across the two files. The changes are committed locally as 3c40718.

Warning

I could not push the commit. Every push attempt (both HEAD and the branch name, via the required git-push.sh wrapper) fails with:

remote: Permission to seqeralabs/docs.git denied to github-actions[bot].
fatal: ... error: 403

The github-actions[bot] token in this run doesn't have write access to the branch. This is a permissions/config issue outside what I can fix from here — the workflow needs permissions: contents: write (and, for PRs from the same repo, an appropriately scoped token). Once that's granted, re-trigger @claude and I'll push, or a maintainer can cherry-pick commit 3c40718.
• docs/azure-batch-native-tutorial

[jonmarti]

Small self-correction on my review — I retracted my earlier comment about the head-pool Autoscale tip (it's now deleted). Turns out the compute-env form does expose a per-pool autoScale control in dual-pool mode (see compute-env-azure-platform.component.ts:271 on master), so the tutorial's tip about disabling Autoscale on the head pool via the UI is accurate as-is. Apologies for the noise — I'd validated against my memory from earlier in the year rather than current master. The other five comments still stand after re-checking the current codebase.

[justinegeffen]

Deslop pass — items flagged for review

A deslop pass landed in 9c4f102 (CTRT tutorial conventions, house prerequisites admonition, heading levels, UI-label alignment, terminology). Three things were left untouched because resolving them needs a factual call rather than an editorial one.

1. The head-node tip may describe the wrong field

The tip in Part 1 says:

To reduce pipeline latency, expand Head job resources, disable Autoscale, and set VMs count to 1. One head node then stays running while the worker pool autoscales independently.

Per compute-envs/azure-batch.md (the VMs count entry), with autoscale disabled VMs count is the fixed size of the compute pool — not the head pool. As written the tip would pin the worker pool to a single VM and disable the autoscaling it claims to preserve. If there is a separate head-pool control that achieves the hot-head-node behaviour, the tip should name it.

2. tower-pool-{envId}-head / -worker is unverified in this repo

Part 1 states the default Forge pool names as tower-pool-{envId}-head and tower-pool-{envId}-worker. Every other page in the repo uses tower-pool-${id} (see the 25.2/25.3 versioned snapshots of this page). Worth confirming the suffixed form against the current Forge implementation before it ships.

3. Three places still say Forge uses a single pool

This PR's premise is that Forge creates separate head and worker pools by default. Three published locations contradict it:

• platform-enterprise_docs/compute-envs/azure-batch.md — the Manual section: "The default Azure Batch implementation uses a single pool for head and compute nodes." (The Pools entry earlier on the same page already says Forge creates two pools, so the page contradicts itself.)
• platform-cloud/docs/troubleshooting_and_faqs/azure_troubleshooting.md — "Use separate Batch pools for head and compute nodes": "The default Azure Batch implementation in Seqera Platform uses a single pool for head and compute nodes."
• platform-enterprise_docs/troubleshooting_and_faqs/azure_troubleshooting.md and the 26.1 snapshot — same entry, same claim.

The FAQ entry is still useful for the low-priority-node recipe (Part 4 now links to it), but its opening claim needs updating if Forge's default has changed.

Smaller notes

• The Enterprise page's "Set up Seqera…" section tells the reader to "Create a new account", which does not apply to an Enterprise deployment. The heading was retitled to Set up Seqera Platform; the steps were left as-is.
• headline: in the frontmatter appears on only these two pages out of ~313 Platform pages, and the page has no date created / last updated / tags keys.
• Part 2 and Part 3 used Location for the region field while Part 1 used Region; these were unified to Region to match compute-envs/azure-batch.md. The credential fields were likewise changed from "Service Principal ID" to the Entra tab's Client ID / Tenant ID / Client secret. Please confirm against the current form.