Add declarative execution environment management to rstudio-connect chart

[lucasrod16]

Summary

• Add executionEnvironments values key for declarative management of execution environments via ExecutionEnvironments.ConfigFilePath
• Requires Connect version 2026.03.0 or later
• Unlike launcher.customRuntimeYaml, changes take effect on every helm upgrade without requiring a pod restart or database reset
• The chart excludes the execution environments ConfigMap from checksum annotations so the kubelet can update the mounted file in-place without triggering a pod restart

Test plan

• just test rstudio-connect — 34 unit tests pass covering ConfigMap rendering, volume/volumeMount, gcfg config injection, checksum absence, custom ConfigFilePath override, launcher coexistence, and validation
• just docs — README regenerated from template
• CI lint and install tests pass

🤖 Generated with Claude Code

[lucasrod16]

Tested on EKS reference architecture cluster. Attached the testing notes as a markdown file

test-notes-execution-environments.md

[dbkegley]

Do we need the extra path segment? Why not just /etc/rstudio-connect/execution-environments.yaml ?

[lucasrod16]

ConfigMap files mounted with subPath don't receive automatic updates from the kubelet, so we need a dedicated directory to avoid overwriting other files in /etc/rstudio-connect/

https://kubernetes.io/docs/concepts/configuration/configmap/#mounted-configmaps-are-updated-automatically

A container using a ConfigMap as a subPath volume mount will not receive ConfigMap updates.

[lucasrod16]

The reason we want automatic updates from the kubelet for this ConfigMap is so that we don't have to restart the Connect pod(s) to apply updates to execution environments

[dbkegley]

Ah, makes sense. Thanks!

[dbkegley]

These changes look good but I'd like folks from SE to weigh in on our docs updates. Let's wait to merge this until after the 2026.03.0 release.

[SamEdwardes]

This is awesome. Thank you for working on this. This is something that has caused a lot of confusion for customers, and a declarative execution environment will be much easier for them to use. I left one comment for discussion.

[SamEdwardes]

This is great that we don't need to redeploy and the Helm chart handles this.

[SamEdwardes]

I would like to go into a little bit more detail about how the settings get merged. If you remove an environment, it will also get removed from Connect. What about execution environments that users might have set manually through the UI? Is there a way to disable users adding environments to the UI or the API so that it is truly only declarative?

[lucasrod16]

fwiw, there are docs that go into more detail about the behavior in the admin guide for execution environments that will be included in the 2026.03.0 release that these helm docs can point to.

Using the declarative management feature does not prevent you from creating environments via UI/API. Connect tracks and manages declarative and UI/API-managed environments separately. Here is what it looks like in the UI:

You cannot create/update/delete environments managed by the declarative configuration using the UI/API, except for ACLs. Environment ACLs currently can only be managed via UI/API.

Is the ask to completely disable managing environments via API/UI when using the declarative approach? Is this what most admins would want and expect from what you've seen?