Enable graceful upgrade of Nexus repo configurations without VM recreation

[Copilot]

Resolves #2721

What is being addressed

Nexus repository configurations were only applied on VM create, via cloud-init. Adding, modifying, or removing a proxy repo in the bundle's nexus_repos_config JSON required destroying and recreating the Nexus VM to take effect — otherwise changes made in the Nexus UI were lost on any redeploy. Shared services also lacked a functioning upgrade path for this.

How is this addressed

• Apply config to the running VM on upgrade — Added an azurerm_virtual_machine_run_command (configure_nexus_repos) whose script base64-embeds the repo config JSONs, realms config, and configure script, writes them onto the VM, and runs the configure script. The run command re-executes whenever its source.script changes, so editing any config file re-applies it to the existing VM. A run command is used rather than a second CustomScript extension because only one CustomScript extension is allowed per VM (cloud_init_wait already uses it); it runs after cloud_init_wait.
• Idempotent repository configuration — configure_nexus_repos.sh now creates each repo (POST, expects 201) and falls back to updating it (PUT to the repo URL, expects 204) when it already exists, so modified repos are applied to a running instance.
• No destructive recreation — Removed repo-config delivery/invocation from cloud-init (custom_data / cloud-config.yaml runcmd) and added ignore_changes = [custom_data] to the VM so config changes no longer force a rebuild.
• Version updates — Nexus runtime image bumped to latest stable 3.94.0; bundle version 3.7.9 → 3.8.0.
• Documentation / CHANGELOG — Updated the shared-services setup docs to describe the upgrade flow, including the caveat that deleting a JSON file does not remove the repo from a running Nexus (must also be removed via the UI/API). Updated CHANGELOG.md.

Known limitations / pending work

• Repository removal is not reconciled: deleting a config file leaves the repo present on the running instance.
• Image tag / other cloud-init changes are not propagated to existing VMs (pre-existing behavior, now explicit via ignore_changes = [custom_data]).

[Copilot]

Pull request overview

This PR improves the Nexus shared service upgrade experience by re-applying repository configuration to an existing VM during upgrades (instead of requiring VM destruction/recreation), and updates the Nexus runtime image and bundle version accordingly.

Changes:

• Add an azurerm_virtual_machine_run_command to copy repo/realm configs to the VM and re-run the Nexus configuration script when config inputs change.
• Update configure_nexus_repos.sh to create-or-update repositories (POST then PUT fallback) so changes apply to existing instances.
• Bump Nexus image tag and bundle version, and document the upgrade behavior + add a CHANGELOG entry.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
templates/shared_services/sonatype-nexus-vm/terraform/vm.tf	Ignore custom_data recreation triggers and add a VM run command to re-apply Nexus repo configuration on upgrade.
templates/shared_services/sonatype-nexus-vm/terraform/configure_nexus_repos_wrapper.sh	New wrapper script to deliver configs/scripts to the VM via run command and invoke configuration.
templates/shared_services/sonatype-nexus-vm/terraform/cloud-config.yaml	Remove repo configuration invocation from cloud-init flow.
templates/shared_services/sonatype-nexus-vm/scripts/configure_nexus_repos.sh	Make repository configuration idempotent by falling back to PUT when POST doesn’t create.
templates/shared_services/sonatype-nexus-vm/porter.yaml	Bump bundle version and Nexus runtime image tag.
docs/tre-admins/setup-instructions/configuring-shared-services.md	Document the new upgrade-based repo configuration flow and its limitations.
CHANGELOG.md	Add enhancement entry for Nexus repo upgrade behavior and image bump.

[marrobi]

@copilot address the pr comments:

Address the following review feedback on this branch:

1. configure_nexus_repos.sh — Add shopt -s nullglob near the top of the script. Without it, when no *.json files exist in nexus_repos_config, the loop runs once with the literal glob and fails through jq/curl into a timeout. Removing all repo JSONs is now a supported upgrade path, so the loop must be skipped cleanly when empty.

2. terraform/vm.tf — Fix the stale comment on the VM lifecycle block. It says config is applied "via the ConfigureNexusRepos extension", but this is now an azurerm_virtual_machine_run_command, not a VM extension. Reword accordingly.

3. Verify PUT status code for Nexus 3.94.0 — The update path treats only 204 as success. Confirm PUT .../repositories/{base}/{type}/{name} still returns 204 in 3.94.0; if it can return 200/202, accept those too so updates aren't retried until timeout.

4. Verify secret handling — configure_nexus_repos_content embeds the admin password into source.script (Terraform state + run command instance view). Confirm this is no worse than the prior cloud-init approach and mark the local sensitive if possible

[Copilot]

@copilot address the pr comments:

Address the following review feedback on this branch:...

Addressed in bdfd2f4.

• Added shopt -s nullglob in configure_nexus_repos.sh so an empty nexus_repos_config directory skips cleanly.
• Updated the stale VM lifecycle comment to reference the configure_nexus_repos run command (not an extension).
• Confirmed 3.94.0 update path expects 204, and made the script tolerant of 200/202/204 to avoid unnecessary retries if behavior varies.
• Marked local.configure_nexus_repos_content as sensitive(...) to reduce plaintext exposure in plan/output; this is not worse than prior cloud-init embedding of the same secret material in rendered config/state.

[github-actions]

Unit Test Results

0 tests   0 ✅  0s ⏱️
0 suites  0 💤
0 files    0 ❌

Results for commit e035496.

♻️ This comment has been updated with latest results.

[SvenAelterman]

LGTM

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 4 comments.

[marrobi]

@copilot Fix the code for all comments in this review thread.

When a review comment includes a suggested change, apply the suggestion exactly.

Do not make changes beyond what is described in the linked review thread.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (2)

templates/shared_services/sonatype-nexus-vm/scripts/configure_nexus_repos.sh:189

• The script captures the HTTP status from the realms configuration request but never validates it, so a failed realms update will be silently ignored and the upgrade will appear successful even though Nexus is left misconfigured.

echo 'Configuring realms...'
status_code=$(curl -iu admin:"$NEXUS_ADMIN_PASSWORD" -XPUT \
  'http://localhost/service/rest/v1/security/realms/active' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \

templates/shared_services/sonatype-nexus-vm/porter.yaml:4

• PR description says the bundle version was bumped to 3.8.0, but porter.yaml sets it to 3.8.2 (and the CHANGELOG entry also mentions 3.8.2). Please reconcile the PR description vs the actual version you intend to release.

version: 3.8.2

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

templates/shared_services/sonatype-nexus-vm/porter.yaml:4

• PR description says the bundle version is bumped from 3.7.9 → 3.8.0, but the code sets it to 3.8.2 (and CHANGELOG also references 3.8.2). Please reconcile this either by updating the PR description or by adjusting this version so the PR metadata matches what will be released.

name: tre-shared-service-sonatype-nexus
version: 3.8.2

[marrobi]

/test 0ca0a96

[github-actions]

🤖 pr-bot 🤖

🏃 Running tests: https://github.com/microsoft/AzureTRE/actions/runs/30096654645 (with refid b9fce06e)

(in response to this comment from @marrobi)

[marrobi]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

Resolved the merge conflicts. The only conflict was in porter.yaml where main was at 3.9.0 (from PR #4981) and our branch was at 3.8.2. I bumped to 3.10.0 (the next minor version above 3.9.0) and updated the CHANGELOG entries accordingly. Merged in commit e035496.

[marrobi]

/test-force-approve e035496

[github-actions]

🤖 pr-bot 🤖

✅ Marking tests as complete (for commit e035496)

(in response to this comment from @marrobi)