Open calvinyv opened 4 years ago
/assign @runzexia @shaowenchen @soulseen /area devops
@calvinyv: The label(s) area/
cannot be applied, because the repository doesn't have them
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.
Currently dockerfile-lint has 100k+ downloads. After I did some research work, I believe that it's worth us to integrate it into ks.
There're three solutions here.
projectatomic/dockerfile-lint
into it
projectatomic/dockerfile-lint
into base Pod Template
projectatomic/dockerfile-lint
into base Pod Template, but add a new flag of ks-installer to control if enable this image
I prefer to choose the option three. Please don't hesitate to leave your comments.
Currently dockerfile-lint has 100k+ downloads. After I did some research work, I believe that it's worth us to integrate it into ks.
There're two solutions here.
Add a new Pod Template, then add image
projectatomic/dockerfile-lint
into it
- (cons) Users need to change the Jenkins agent in their pipeline (aka Jenkinsfile) if they want to docker and lint the docker images
- (cons) Users cannot choose different agents via UI, but they can choose it via editing Jenkinsfile
- (pros) will not increase the number of containers in a Pod Template, less memory, and CPU resources usage
Add image
projectatomic/dockerfile-lint
into base Pod Template
- (cons) Increase the number of contains in all Pod Templates
- (cons) It's not a good practice which always adding a new container into all Pod Templates
- (pros) Users don't need to choose different agents
- (pros) Not increase a new Pod Template
Add image
projectatomic/dockerfile-lint
into base Pod Template, but add a new flag of ks-installer to control if enable this image
- This is an improved version of solution 2. We don't offer this new container by default. Users can enable it via ks-installer/ks-devops. That means we need to add a new flag in ks-installer/ks-devops.
- (cons) Make ks-installer/ks-devops becomes more complicated.
- (pros) This is a user-chosen solution. We can follow the same pattern if there're other any new contains which are useful.
I prefer to choose solution two. Please don't hesitate to leave your comments.
you said two solutions but posted three? @_@
My bad. Sorry for the mistake. I've fixed it.
It is not suitable to integrate directly into the DevOps. We can use it as a solution.
Refer to this tech article sharing, some tools has ability to scan Dockfile and find the potential illegal issues, and some customers hope this could happen in ks.
https://mp.weixin.qq.com/s/z9ybN3iS3jD6tikjLoG_2Q