Operator-sdk: Move Dockerfile to the project root
In case the operator implementation requires changes to be made to the Dockerfile (most likely) we'd commit the changes made to Dockerfile to GitHub. Since the Dockerfile generated by the operator-sdk is placed under tmp/build developers inadvertently may commit the whole tmp/ directory which is not desirable.
Suggest moving the Dockerfile at the root of the project.
matyix
All 7 comments
That is true. One caveat is that we would like to be able to generate it again with changes if the operator sdk is updated.
We can achieve this by having two dockerfiles. I'll propose a patch for this and we can see if it is appropriate.
spahl
on 24 Apr 2018
thx @spahl @fanminshi let me know if you have a patch/feature branch available, happy to test it.
matyix
on 24 Apr 2018
One option to consider is to invert the relationship between docker build and operator-sdk build. In other words, use a multi-stage Docker build that first invokes operator-sdk build and then copies the build outputs into the final image. This would provide an easy and natural way to customize the Dockerfile, and would make it possible to encapsulate the Operator SDK installation into an image.
EronWright
on 31 Jul 2018
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle stale
openshift-bot
on 9 May 2019
Stale issues rot after 30d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
/remove-lifecycle stale
openshift-bot
on 8 Jun 2019
Rotten issues close after 30d of inactivity.
Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.
/close
openshift-bot
on 8 Jul 2019
@openshift-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue by commenting
/reopen.
Mark the issue as fresh by commenting/remove-lifecycle rotten.
Exclude this issue from closing again by commenting/lifecycle frozen./close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
openshift-ci-robot
on 8 Jul 2019
Related issues
kristiandrucker
路
5Comments
nrvnrvn
路
3Comments
chowmean
路
5Comments
flickerfly
路
5Comments
camilamacedo86
路
4Comments
Most helpful comment
One option to consider is to invert the relationship between
docker buildandoperator-sdk build. In other words, use a multi-stage Docker build that first invokesoperator-sdk buildand then copies the build outputs into the final image. This would provide an easy and natural way to customize theDockerfile, and would make it possible to encapsulate the Operator SDK installation into an image.