Dmitrii Unterov (878ad31f) at 27 Mar 16:04
feat: image scan jobs for every image we build: make pre-build happy
@rk725 I just submitted the MR, please take a look when you have a chance. So the concept is "better than nothing"
We will have scan job for every image we have, including autogenerated jobs. Yes, we will not have it all in "vulnerability report" tab, but at least we can inspect the results manually.
Closes #83
Dmitrii Unterov (d0a619b1) at 27 Mar 15:56
feat: image scan jobs for every image we build
check if it is possible at all (i.e. having the second node pool with the same name)
Mmm. Yes. We might want to have something like local.pool_generation
or similar appended to the pool name which we can bump if there's a change necessitating a pool re-creation.
Refinement notes:
OK, this seems like it might be quite a bit of effort then, or even impossible to integrate with the nice GitLab UI reports. I'm away the first half of next week but when I'm back let's catch up and see if we can come up with a way forward. Otherwise we might have to close this off for the time being. Thanks for your investigation so far
Hi! I experimented for some time with this in my temp repository (experiments/du228-docker-image-scan-test) and it seems it will be difficult (if even possible) to integrate the scan results to the vulnerability report page.
I tried to add "container_scanner" provided by GitLab autodevops - Container-Scanning.gitlab-ci.yml (docs)
It works just fine for single image project, because this job produces the artifact with name "container_scanning" and according to docs this artifact is used for "display the results of one or more reports in":
Which is good and fancy, but the problem is we only can have it for one container per project
Here's an example: https://gitlab.developers.cam.ac.uk/uis/devops/experiments/du228-docker-image-scan-test/-/pipelines/491376
3 build jobs, 3 dependent scan jobs
But the "vulnerability report" contains only data from the job that finished last - https://gitlab.developers.cam.ac.uk/uis/devops/experiments/du228-docker-image-scan-test/-/security/vulnerability_report
It seems the related "proposal" is open for 3 years on GitLab site - https://gitlab.com/groups/gitlab-org/-/epics/3139#proposal
Based on this, I'd say we can't have this fancy built-in integration of container scan (in UI) for multiple images. Of course we can set up it without UI integration, for example we could setup scheduled job to detect only critical issue and somehow analyse the report, but this is much less convenient than doing it in GitLab UI.
I thought about different implementations:
Sam Wenham (00b9d888) at 15 Mar 12:35
fix: Add the readme
Sam Wenham (dd0f7f79) at 15 Mar 11:42
feat: Add tests
Resolves #19
In https://gitlab.developers.cam.ac.uk/uis/devops/devhub/gitlab-runner-infrastructure/-/issues/31#note_599611 we had to perform an emergency upgrade of a node pool. In testing it was noted that terraform destroys the existing node pool before creating the replacement.
Investigate using the create_before_destroy
lifecycle meta-argument on the node pool resource to ensure that a new node pool is created before the old one is destroyed. This allows for workload migration.
The run_tests.sh -t
option will run all tests if no file is listed.
This should fail if no param is passed
Dr Rich Wareham (370de7bc) at 12 Mar 11:53
Examples:
This could be due to the heavy process of compiling dlib for both the AMD64 and ARM64 platforms at the same time.
These tests often fail due to google's eventually consistent APIs!! I've rerun the tests and they're passing now so I've merged the MR. Thanks against for this, good work!
Dmitrii Unterov (0321edff) at 07 Mar 17:48