docs: document configuration-level runtime.tag

extend/docker-runner/index.md

@@ -86,7 +86,8 @@ all of them are optional:
 - `storage` --- configuration of [input and output mapping](/extend/common-interface/folders/); specific options correspond to the options of the
 [unload data](https://keboola.docs.apiary.io/#reference/tables/unload-data-asynchronously) and
 [load data](https://keboola.docs.apiary.io/#reference/tables/load-data-asynchronously) API calls.
-- `runtime` --- configuration for modifying some image parameters at run time
+- `runtime` --- [runtime settings](/integrate/jobs/#job-runtime-configuration) (`tag`, `backend`, `parallelism`); most notably `runtime.tag`
+pins the Docker image tag that jobs of this configuration run, which is the usual way of testing a development build of a component
 - `processors` --- configuration of [Processors](/extend/component/processors/)
 - `authorization` --- OAuth authorization [injected to the configuration](/extend/common-interface/oauth/); not stored in the component configuration
 - `image_parameters` --- an arbitrary object passed from the [component](/extend/component/); not stored in the component configuration

integrate/jobs/index.md

@@ -243,7 +243,7 @@ Use the `forceRun` mode to run a configuration that is disabled. The `debug` can
 
 ### Job Runtime configuration
 You may provide runtime settings for a job. Runtime settings do not affect what the job does, it affects how the job does it. Current 
-available runtime settings are `backend` and `parallelism`. The `backend` parameter defines what Snowflake warehouse is used for the job and currently
+available runtime settings are `backend`, `parallelism` and `tag`. The `backend` parameter defines what Snowflake warehouse is used for the job and currently
 affects mostly Snowflake transformations. Available values for backend size come from [Workspace Create API call](https://keboola.docs.apiary.io/#reference/workspaces/workspaces-collection/create-workspace) and are `small`, `medium`, `large`. 
 
 The `parallelism` allows to run [Configuration Rows](https://help.keboola.com/components/#configuration-rows) (if present in the configuration) in
@@ -255,6 +255,25 @@ Runtime parameters can be specified on various levels. The values can be specifi
 when creating a job, in which case it overrides the configuration. It may also be specified for an orchestration, in which case it overrides what is specified 
 in individual jobs of that orchestration.
 
+When stored in the component configuration, the runtime settings live in a top-level `runtime` node of the configuration JSON — a sibling of `parameters`, 
+not inside it. For example, to pin all jobs of a configuration to a specific image tag:
+
+{% highlight json %}
+{
+    "parameters": {
+        "...": "..."
+    },
+    "runtime": {
+        "tag": "my-branch-3"
+    }
+}
+{% endhighlight %}
+
+Jobs of this configuration then run the given image tag (the job detail shows the resolved value in its `tag` field) until the `runtime.tag` key 
+is removed from the configuration. This is the usual way of testing a development build of a component in a single project without affecting 
+other projects — the tag in the [Developer Portal](/extend/publish/) stays untouched. Do not forget to remove the key when done; a pinned 
+configuration keeps running the old image even after new versions of the component are released.
+
 ### Job Type
 Job can be of one of the four types `standard`, `container`, `phaseContainer` and `orchestrationContainer`. The `standard` is something which does actual work.
 Only standard jobs consume billable time and are counted towards consumption of any resources. Other job types are virtual containers encapsulating standard jobs.