For others bumping into this:
I found two problems with the Camunda Run deployments when it comes to embedded forms:
Incremental deployment
Camunda Run sets the “deploy changed only” flag for the engine (setDeployChangedOnly(true); in CamundaBpmRunProcessEngineConfiguration.java.
This seems unnecessary and causes the form redeployment bug when form references are rendered inoperable when a process-only change is deployed as part of a second-deployment.
NOTE: when all of the files are unchanged there will be NO new deployment anyways, since the “deployment duplicate filtering” feature is still active in the default deployment config (which is a better mechanism than “deployed changed only”, see the REST API /deployment for details).
The starting “/” in the form resource path in the form-keys (like "embedded:deployment:/StartForm.html).
Again, this seems to be unnecessary and breaks compatibility with the Modeller deployment (especially when all resources are in a single folder).
Seems like more of a bug to me in CamundaBpmRunProcessEngineConfiguration.java than something the Camunda team actually wanted. One more character could be chopped off when the deployment resource name is constructed from the absolute filesystem path of the resource (and that would make it unnecessary to put the “/” in the form keys). That way Modeller deployment and Spring Boot deployment result in the same deployment resource names (except: resources in subfolders)
Solution:
I simply ported the engine initialization classes from Camunda Run (sources here: https://github.com/camunda/camunda-bpm-platform/tree/master/distro/run) and fixed the above two problems for our own Spring Boot process app.
If you need to use Camunda Run (not your own SpringBoot app), you can fork the repo and fix these for yourself.