docs: update docs to mention that files are extracted from source where source code is available

Recent Dokku changes invalidate a bunch of docs around where files need to be placed in order for Dokku to respect them. This doc change clarifies where files are extracted from in cases where source code is available, which should hopefully make users less confused about how the system works.

See https://railsnotes.xyz/blog/deploying-ruby-on-rails-with-dokku-redis-sidekiq-arm-docker-hetzner for the inspiration - I was reading through it and was like 'these docs are definitely incorrect...'.

docs/deployment/builders/cloud-native-buildpacks.md

@@ -60,8 +60,10 @@ dokku builder:set node-js-app selected pack
 
 When deploying a monorepo, it may be desirable to specify the specific path of the `project.toml` file to use for a given app. This can be done via the `builder-pack:set` command. If a value other than `project.toml` is specified and that file does not exist in the app's build directory, Dokku will continue the build process as if the repository has no `project.toml`.
 
+For deploys via the `git:from-image` and `git:load-image` commands, the `project.toml` is extracted from the configured `WORKDIR` property of the image. For all other deploys - git push, `git:from-archive`, `git:sync` - will have the `project.toml` extracted directly from the source code. Both cases will respect the configured `projecttoml-path` property value.
+
 ```shell
-dokku builder-pack:set node-js-app projecttoml-path project2.toml
+dokku builder-pack:set node-js-app projecttoml-path .dokku/project.toml
 ```
 
 The default value may be set by passing an empty value for the option:

docs/deployment/builders/dockerfiles.md

@@ -38,6 +38,8 @@ dokku config:unset --no-restart node-js-app DOKKU_PROXY_PORT_MAP
 
 When deploying a monorepo, it may be desirable to specify the specific path of the `Dockerfile` file to use for a given app. This can be done via the `builder-dockerfile:set` command. If a value is specified and that file does not exist in the app's build directory, then the build will fail.
 
+For git push, `git:from-archive`, and `git:sync` workflows, the `Dockerfile` is extracted directly from the source code, respecting the configured `dockerfile-path` property value.
+
 ```shell
 dokku builder-dockerfile:set node-js-app dockerfile-path Dockerfile2
 ```
@@ -197,10 +199,7 @@ Setting `$DOKKU_DOCKERFILE_CACHE_BUILD` to `true` or `false` will enable or disa
 > New as of 0.5.0
 
 You can also customize the run command using a `Procfile`, much like you would on Heroku or
-with a buildpack deployed app. The `Procfile` should contain one or more lines defining [process types and associated commands](https://devcenter.heroku.com/articles/procfile#declaring-process-types).
-When you deploy your app, a Docker image will be built. The `Procfile` will be extracted from the image
-(it must be in the folder defined in your `Dockerfile` as `WORKDIR` or `/app`) and the commands
-in it will be passed to `docker run` to start your process(es). Here's an example `Procfile`:
+with a buildpack deployed app. The `Procfile` should contain one or more lines defining [process types and associated commands](https://devcenter.heroku.com/articles/procfile#declaring-process-types). The commands in your app's Procfile will be passed to `docker run` to start your process(es). Here's an example `Procfile`:
 
 ```Procfile
 web: bin/run-prod.sh
@@ -216,12 +215,11 @@ COPY . ./
 CMD ["bin/run-dev.sh"]
 ```
 
-When you deploy this app the `web` process will automatically be scaled to 1 and your Docker container
-will be started basically using the command `docker run bin/run-prod.sh`. If you want to also run
-a worker container for this app, you can run `dokku ps:scale worker=1` and a new container will be
-started by running `docker run bin/run-worker.sh` (the actual `docker run` commands are a bit more
-complex, but this is the basic idea). If you use an `ENTRYPOINT` in your `Dockerfile`, the lines
-in your `Procfile` will be passed as arguments to the `ENTRYPOINT` script instead of being executed.
+When the above example is deployed, the `web` process is started, with the command `bin/run-prod.sh` executed in the container. All other processes must be scaled up separately. If the app's `Dockerfile` contains an `ENTRYPOINT` directive, the command specified in the `Procfile` will be passed to that entrypoint script as an argument.
+
+See the [scaling apps documentation](/docs/processes/process-management.md#scaling-apps) for more information on how process scaling is performed.
+
+See the [app.json location documentation](/docs/processes/process-management.md#changing-the-procfile-location) for more information on where to place your `Procfile` file.
 
 ### Exposed ports
 

docs/deployment/builders/lambda.md

@@ -43,8 +43,10 @@ The `lambda` builder plugin delegates all build logic to [lambda-builder](https:
 
 When deploying a monorepo, it may be desirable to specify the specific path of the `lambda.yml` file to use for a given app. This can be done via the `builder-lambda:set` command. If a value is specified and that file does not exist in the app's build directory, then the build will fail.
 
+For deploys via the `git:from-image` and `git:load-image` commands, the `lambda.yml` is extracted from the configured `WORKDIR` property of the image. For all other deploys - git push, `git:from-archive`, `git:sync` - will have the `lambda.yml` extracted directly from the source code. Both cases will respect the configured `lambdayml-path` property value.
+
 ```shell
-dokku builder-lambda:set node-js-app lambdayml-path lambda2.yml
+dokku builder-lambda:set node-js-app lambdayml-path .dokku/lambda.yml
 ```
 
 The default value may be set by passing an empty value for the option: