Bug: Git over HTTP/HTTPs Release URLs do not work in Runtime Config / Addons

[maxim-hansen]

Describe the bug
Given the following runtime config:

releases:
- name: elastic
  version: 1.0.0
  url: git+https://github.com/some-org/elastic-release

addons:
- name: elastic-agent
  include:
    stemcell:
    - os: ubuntu-jammy
    - os: ubuntu-noble
  jobs:
  - name: elastic-agent
    release: elastic

And the following deployment manifest:

name: test

releases:
- name: dummy
  version: latest

stemcells:
- alias: default
  os: ubuntu-jammy
  version: latest

update:
  canaries: 1
  canary_watch_time: 10000-600000
  max_in_flight: 1
  update_watch_time: 10000-600000

instance_groups:
- name: rc-test
  instances: 1
  azs: [z1]
  networks:
  - name: default
  vm_type: small
  stemcell: default
  jobs:
  - name: noop
    release: dummy

variables: []

And assumig that the elastic release is not uploaded/available on the Director beforehand, you will get the following error when runnig a bosh deploy command after adding the runtime configuration:

$ bosh -d test deploy manifest.yml
Using environment 'xxx' as client 'xxx'

Using deployment 'test'

  releases:
+ - name: elastic
+   url: git+https://github.com/some-org/elastic-release
+   version: 1.0.0
  
  addons:
+ - include:
+     stemcell:
+     - os: ubuntu-jammy
+     - os: ubuntu-noble
+   jobs:
+   - name: elastic-agent
+     release: elastic
+   name: elastic-agent

Continue? [yN]: y

Task 464125

Task 464125 | 11:14:44 | Error: Release 'elastic' doesn't exist

Task 464125 Started  Sat Apr 11 11:14:44 UTC 2026
Task 464125 Finished Sat Apr 11 11:14:44 UTC 2026
Task 464125 Duration 00:00:00
Task 464125 error

Updating deployment:
  Expected task '464125' to succeed but state is 'error'

Exit code 1

However, if the exact same config is simply moved to the deployment manifest directly, instead of being merged in from the runtime config, then everything works as expected. Meaning that the missing release is downloaded from the provided URL:

$ bosh -d test deploy manifest.yml 
Using environment 'xxx' as client 'xxx'

Using deployment 'test'

[----------------------------------------------------] 100.00% 555.97 MiB/s 1.5s
Task 464126

Task 464126 | 11:19:23 | Extracting release: Extracting release (00:00:05)
Task 464126 | 11:19:28 | Verifying manifest: Verifying manifest (00:00:00)
Task 464126 | 11:19:28 | Resolving package dependencies: Resolving package dependencies (00:00:00)
Task 464126 | 11:19:28 | Creating new packages: elastic-agent-8/086f4b39c6adcaf55353e1445f7ac672f431bc11b41838ead21630f0eacbe0de (00:00:03)
Task 464126 | 11:19:31 | Creating new packages: elastic-agent-9/b6a872f7ded37ac6925f0f1b27002556c00f7cbb1ce82c0c443a01f36b2b5d34 (00:00:04)
Task 464126 | 11:19:35 | Creating new jobs: elastic-agent/a62496ab29183b8772f3534e79a01ba1959e37cbd8344508649c76f41c1b8ace (00:00:00)
Task 464126 | 11:19:35 | Release has been created: elastic/1.0.0 (00:00:00)

Task 464126 Started  Sat Apr 11 11:19:23 UTC 2026
Task 464126 Finished Sat Apr 11 11:19:35 UTC 2026
Task 464126 Duration 00:00:12
Task 464126 done
  releases:
+ - name: elastic
+   url: git+https://github.com/some-org/elastic-release
+   version: 1.0.0
.
.
.

To Reproduce
Steps to reproduce the behavior:

1. Create a new runtime config containing a release that is not previously uploaded to the BOSH Director, and that is using the git+https URL syntax.
2. Perform a deployment, and observe that the BOSH CLI does not attempt to download and upload the release to the BOSH Director, causing the deployment to fail.

Expected behavior
Given that the documentation in Director Runtime Config does not indicate that the full set of Release URLs is not supported, one expects that the BOSH CLI will treat the resulting manifest (runtime+deployment) the same way as if the information was only coming in from the deployment manifest alone.

All forms of the Release URLs should be supported regardless of where the releases: section is defined (runtime/addons/manifest).

Versions

• BOSH CLI version: 7.10.2
• BOSH version: 282.1.6

Additional information
There was no different in behaviour if this was a brand new deployment or, like in the above example, if the "new" runtime config was attempted to be added to an already existing deployment. I tested with both, but provided logs/examples for the latter.