Because all projects tend to be built slightly differently, some assumptions and generalizations have been made about how to build in each language. It is assumed that if these choices do not work for your project, you know enough to make decisions about what the settings should be.
Go
The project uses go modules. This is the defacto standard for go projects and if your project does not use go modules you should strongly consider migrating
The project vendors its builds PRIOR to copying the project into its docker image.
Go builds can use the '-mod=vendor' flag in build stages to avoid pulling private repositories and speed up builds
All go projects SHOULD use scratch images. Non-scratch images should be an exception to the standard
Node
The application can run as an unpriviged user
Anything below node10 is considered EoL and should be upgraded
As a default, /app is the directory for copying and building
jnjackins
commented
4 years ago
:whale: This is an automatically generated PR. :whale:
This PR should work out of the box in most situations. However, you should test and modify as needed just like any other code change.
This PR attempts to automatically upgrade this repository and its associated Dockerfile to follow best security and build practices.
Legend :white_check_mark: = great, you've got it covered! :stop_sign: = uh oh. This needs to be fixed!
For additional help, please visit the #docker channel in slack!
Repository Best Practice Checks
Dockerfile Best Practice Checks
Detected Language: golang
desired: scratch
desired: golang:1.14-alpine
desired: scratch
Language Specific Dockerfile Choices
Because all projects tend to be built slightly differently, some assumptions and generalizations have been made about how to build in each language. It is assumed that if these choices do not work for your project, you know enough to make decisions about what the settings should be.
Go
Node