|
| 1 | +# ADR 0096: Hook extensions |
| 2 | + |
| 3 | +**Date:** 3 August 2023 |
| 4 | + |
| 5 | +**Status**: Proposed <!--Accepted|Rejected|Superceded|Deprecated--> |
| 6 | + |
| 7 | +## Context |
| 8 | + |
| 9 | +The current implementation of container hooks does not allow users to customize the pods created by the hook. While the implementation is designed to be used as is or as a starting point, building and maintaining a custom hook implementation just to specify additional fields is not a good user experience. |
| 10 | + |
| 11 | +## Decision |
| 12 | + |
| 13 | +We have decided to add hook extensions to the container hook implementation. This will allow users to customize the pods created by the hook by specifying additional fields. The hook extensions will be implemented in a way that is backwards-compatible with the existing hook implementation. |
| 14 | + |
| 15 | +To allow customization, the runner executing the hook should have `ACTIONS_RUNNER_CONTAINER_HOOK_TEMPLATE` environment variable pointing to a yaml file on the runner system. The extension specified in that file will be applied both for job pods, and container steps. |
| 16 | + |
| 17 | +If environment variable is set, but the file can't be read, the hook will fail, signaling incorrect configuration. |
| 18 | + |
| 19 | +If the environment variable does not exist, the hook will apply the default spec. |
| 20 | + |
| 21 | +In case the hook is able to read the extended spec, it will first create a default configuration, and then merged modified fields in the following way: |
| 22 | + |
| 23 | +1. The `.metadata` fields that will be appended if they are not reserved are `labels` and `annotations`. |
| 24 | +2. The pod spec fields except for `containers` and `volumes` are applied from the template, possibly overwriting the field. |
| 25 | +3. The volumes are applied in form of appending additional volumes to the default volumes. |
| 26 | +4. The containers are merged based on the name assigned to them: |
| 27 | + 1. If the name of the container *is not* "$job", the entire spec of the container will be added to the pod definition. |
| 28 | + 2. If the name of the container *is* "$job", the `name` and the `image` fields are going to be ignored and the spec will be applied so that `env`, `volumeMounts`, `ports` are appended to the default container spec created by the hook, while the rest of the fields are going to be applied to the newly created container spec. |
| 29 | + |
| 30 | +## Consequences |
| 31 | + |
| 32 | +The addition of hook extensions will provide a better user experience for users who need to customize the pods created by the container hook. However, it will require additional effort to provide the template to the runner pod, and configure it properly. |
0 commit comments