You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This repo contains code to build a vscode devcontainers that can be used as a base image for all EPS projects.
6
-
Images are build for amd64 and arm64 and a manifest file created that can be pulled for both architectures. This is then pushed to github container registry.
7
-
Images are built using using https://github.com/devcontainers/cli.
24
+
This repository contains code to build VS Code devcontainers that can be used as a base image for all EPS projects.
25
+
Images are built for AMD64 and ARM64, and a manifest file is created that can be pulled for both architectures. This is then pushed to GitHub Container Registry.
26
+
Images are built using https://github.com/devcontainers/cli.
8
27
9
28
We build a base image based on mcr.microsoft.com/devcontainers/base:ubuntu-22.04 that other images are then based on
10
29
@@ -16,23 +35,23 @@ The base image contains
16
35
17
36
It installs the following dev container features
18
37
- docker outside of docker
19
-
-github cli
38
+
-GitHub CLI
20
39
21
40
As the vscode user the following also happens
22
41
23
42
asdf install and setup for these so they are available globally as vscode user
24
43
- shellcheck
25
44
- direnv
26
45
- actionlint
27
-
- ruby (for github pages)
28
-
-trivy
46
+
- ruby (for GitHub Pages)
47
+
-Trivy
29
48
- yq
30
49
31
50
Install and setup git-secrets
32
51
33
52
# Using the images
34
53
## Project setup
35
-
In each eps project, `.devcontainer/Dockerfile` should be set to
54
+
In each EPS project, `.devcontainer/Dockerfile` should be set to
36
55
```
37
56
ARG IMAGE_NAME=node_24_python_3_14
38
57
ARG IMAGE_VERSION=latest
@@ -49,7 +68,7 @@ RUN if [ -n "${DOCKER_GID}" ]; then \
49
68
usermod -aG docker vscode; \
50
69
fi
51
70
```
52
-
`.devcontainer/devcontainer.json` should be set to.
71
+
`.devcontainer/devcontainer.json` should be set to:
53
72
```
54
73
{
55
74
"name": "eps-common-workflows",
@@ -82,13 +101,13 @@ RUN if [ -n "${DOCKER_GID}" ]; then \
82
101
}
83
102
}
84
103
```
85
-
Note - this file will be used in github workflows to calculate the version of container to use in builds, so it must be valid JSON (no comments).
104
+
Note - this file will be used in GitHub workflows to calculate the version of container to use in builds, so it must be valid JSON (no comments).
86
105
The name should be changed to match the name of the project.
87
106
IMAGE_NAME and IMAGE_VERSION should be changed as appropriate.
88
107
You should not need to add any features as these are already baked into the image
89
108
90
-
## Getting image name and version in github actions
91
-
This job should be used in github actions wherever you need to get the dev container name or tag
109
+
## Getting image name and version in GitHub Actions
110
+
This job should be used in GitHub Actions wherever you need to get the dev container name or tag
92
111
93
112
```
94
113
get_config_values:
@@ -107,9 +126,9 @@ This job should be used in github actions wherever you need to get the dev conta
- the image specified uses the tag starting githubactions-
137
156
- there is `options: --user 1001:1001 --group-add 128` below image to ensure it uses the correct user id and is added to the docker group
138
157
- the default shell is set to be bash
139
158
- the first step copies .tool-versions from /home/vscode to $HOME/.tool-versions
140
-
## Using local or pull request images in visual studio code
159
+
## Using local or pull request images in Visual Studio Code
141
160
You can use local or pull request images by changing IMAGE_VERSION in devcontainer.json.
142
161
For an image built locally following instructions below, you should put the IMAGE_VERSION=local-build.
143
-
For an image built from a pull request, you should put the IMAGE_VERSION=<tagofimageasshowinpullrequestjob>.
144
-
You can only use images built from a pull request for testing changes in github actions.
162
+
For an image built from a pull request, you should put the IMAGE_VERSION=<tagofimageasshowninpullrequestjob>.
163
+
You can only use images built from a pull request for testing changes in GitHub Actions.
145
164
146
165
# Project structure
147
166
We have 5 types of dev container. These are defined under src
@@ -150,35 +169,35 @@ We have 5 types of dev container. These are defined under src
150
169
`base_node` - images that install node - most language projects rely on one of these
151
170
`languages` - this installs specific versions of python - normally based off a node image
152
171
`projects` - this is used for projects where more customization is needed than just a base language image.
153
-
`githubactions` - this just takes an existing image and remaps vscode user to be 1001 so it can be used by github actions.
172
+
`githubactions` - this just takes an existing image and remaps vscode user to be 1001 so it can be used by GitHub Actions.
154
173
155
174
Each image to be built contains a .devcontainer folder that defines how the devcontainer should be built. At a minimum, this should contain a devcontainer.json file. See https://containers.dev/implementors/json_reference/ for options for this
156
175
157
-
Images under languages should point to a dockerfile under src/common or src/common_node_24 that is based off the base or node image. This also runs `.devcontainer/scripts/root_install.sh` and `.devcontainer/scripts/vscode_install.sh` as vscode user as part of the build. These files should be in the language specific folder.
176
+
Images under languages should point to a Dockerfile under src/common or src/common_node_24 that is based off the base or node image. This also runs `.devcontainer/scripts/root_install.sh` and `.devcontainer/scripts/vscode_install.sh` as vscode user as part of the build. These files should be in the language specific folder.
158
177
159
-
We use trivy to scan for vulnerabilities in the built docker images. Known vulnerabilities in the base image are in `src/common/.trivyignore.yaml`. Vulnerabilities in specific images are in `.trivyignore.yaml`file in each images folder. These are combined before running a scan to exclude all known vulnerabilities
178
+
We use Trivy to scan for vulnerabilities in the built Docker images. Known vulnerabilities in the base image are in `src/common/.trivyignore.yaml`. Vulnerabilities in specific images are in `.trivyignore.yaml`files in each image folder. These are combined before running a scan to exclude all known vulnerabilities
160
179
161
180
# Pull requests and merge to main process
162
-
For each pull request, and merge to main, images are built and scanned using trivy, and pushed to github docker registry.
163
-
Docker images are built for amd64 and arm64 architecture, and a combined manifest is created and pushed as part of the build.
164
-
The main images have a vscode user with id 1000. A separately tagged image is also created with user vscode mapped to user id 1001 so they can be used by github actions.
181
+
For each pull request, and merge to main, images are built and scanned using Trivy, and pushed to GitHub Container Registry.
182
+
Docker images are built for AMD64 and ARM64 architecture, and a combined manifest is created and pushed as part of the build.
183
+
The main images have a vscode user with ID 1000. A separately tagged image is also created with the vscode user mapped to user ID 1001 so it can be used by GitHub Actions.
165
184
166
185
The base image is built first, and then language images, and finally project images.
167
186
168
-
Docker images are scanned for vulnerabilities using trivy as part of a build step, and the build fails if vulnerabilities are found not in .trivyignore file.
187
+
Docker images are scanned for vulnerabilities using Trivy as part of a build step, and the build fails if vulnerabilities are found that are not in the .trivyignore file.
169
188
170
189
For pull requests, images are tagged with the pr-{pull request id}-{short commit sha}.
171
190
For merges to main, images are tagged with the ci-{short commit sha}.
172
-
Github actions images are tagged with githubactions-{full tag}
173
-
Amd64 images are tagged with {tag}-amd64
174
-
Arm64 images are tagged with {tag}-arm64
175
-
Combined image manifest image is just tagged with {tag} so can be included in devcontainer.json and the correct image is pulled based on the host architecture.
191
+
GitHub Actions images are tagged with githubactions-{full tag}
192
+
AMD64 images are tagged with {tag}-amd64
193
+
ARM64 images are tagged with {tag}-arm64
194
+
The combined image manifest is tagged with {tag}, so it can be included in devcontainer.json and the correct image is pulled based on the host architecture.
176
195
177
-
When a pull request is merged to main or closed, all associated images are deleted from the registry using the github workflow delete_old_images
196
+
When a pull request is merged to main or closed, all associated images are deleted from the registry using the GitHub workflow delete_old_images
178
197
179
198
# Release workflow
180
199
There is a release workflow that runs weekly at 18:00 on Thursday and on demand.
181
-
This creates a new release tag, builds all images, and pushes them to github container registry.
200
+
This creates a new release tag, builds all images, and pushes them to GitHub Container Registry.
182
201
Images are tagged with the release tag, and also with latest
You can generate a .trivyignore file for known vulnerabilities by either downloading the json scan output generated by the build, or by generating it locally using the scanning images commands above with a make target of scan-image-json
307
+
You can generate a .trivyignore file for known vulnerabilities by either downloading the JSON scan output generated by the build, or by generating it locally using the scanning images commands above with a make target of scan-image-json
289
308
290
309
If generated locally, then the output goes into .out/scan_results_docker.json.
291
-
You can use github cli tools to download the scan output file. Replace the run id from the url, and the -n with the filename to download
310
+
You can use GitHub CLI tools to download the scan output file. Replace the run ID from the URL, and the -n with the filename to download
292
311
```
293
312
gh run download <run id> -n scan_results_docker_fhir_facade_api_arm64.json
294
313
```
@@ -305,7 +324,7 @@ poetry run python \
305
324
306
325
## Cleaning up unused container images
307
326
308
-
There is a script to delete unused container images. This runs on every merge to main, and deletes pull request images, and on a weekly schedule which deletes images created by ci.
327
+
There is a script to delete unused container images. This runs on every merge to main and deletes pull request images, and on a weekly schedule it deletes images created by CI.
309
328
You can run it manually using the following. Using the `dry-run` flag just shows what would be deleted
310
329
311
330
```
@@ -323,16 +342,16 @@ Flags:
323
342
324
343
If neither `--delete-pr` nor `--delete-ci` is set, the script defaults to `--delete-pr`.
325
344
326
-
## Common makefile targets
327
-
There are a set of common Makefiles that are defined in `src/base/.devcontainer/Mk` and are included from `common.mk`. These are installed to /usr/local/share/eps/Mk on the base image so are available for all containers.
345
+
## Common Makefile targets
346
+
There is a set of common Makefiles that are defined in `src/base/.devcontainer/Mk` and are included from `common.mk`. These are installed to /usr/local/share/eps/Mk on the base image, so they are available for all containers.
328
347
329
-
This should be added to the end of each projects Makefile to include them
348
+
This should be added to the end of each project's Makefile to include them
330
349
```
331
350
%:
332
351
@$(MAKE) -f /usr/local/share/eps/Mk/common.mk $@
333
352
```
334
353
### Targets
335
-
The following targets are defined. These are needed for quality checks to run. Some targets are projectspecific and so should be overridden in the projects Makefile.
354
+
The following targets are defined. These are needed for quality checks to run. Some targets are project-specific and should be overridden in the project's Makefile.
336
355
337
356
Build targets (`build.mk`)
338
357
-`install` - placeholder target - should be overridden locally
@@ -350,14 +369,14 @@ Check targets (`check.mk`)
350
369
-`cfn-guard-cloudformation` - validates `cloudformation` templates against cfn-guard rulesets and writes outputs to `.cfn_guard_out/`
351
370
-`cfn-guard-cdk` - validates `cdk.out` against cfn-guard rulesets and writes outputs to `.cfn_guard_out/`
352
371
-`cfn-guard-terraform` - validates `terraform_plans` against cfn-guard rulesets and writes outputs to `.cfn_guard_out/`
353
-
-`actionlint` - runs actionlint against github actions
354
-
-`secret-scan` - runs git-secrets (including scanning history) against the repo
372
+
-`actionlint` - runs actionlint against GitHub Actions
373
+
-`secret-scan` - runs git-secrets (including scanning history) against the repository
355
374
-`guard-<ENVIRONMENT_VARIABLE>` - checks if an environment variable is set and errors if it is not
356
375
357
376
Credentials targets (`credentials.mk`)
358
-
-`aws-configure` - configures an AWS sso session
359
-
-`aws-login` - Authorizes an sso session with AWS so aws cli tools can be used. You may still need to set AWS_PROFILE before running commands
360
-
-`github-login` - Authorizes github cli to github with scope to read packages
377
+
-`aws-configure` - configures an AWS SSO session
378
+
-`aws-login` - Authorizes an SSO session with AWS so AWS CLI tools can be used. You may still need to set AWS_PROFILE before running commands
379
+
-`github-login` - Authorizes GitHub CLI to GitHub with scope to read packages
361
380
-`create-npmrc` - depends on `github-login`, then writes `.npmrc` with a GitHub Packages auth token and `@nhsdigital` registry
0 commit comments