search

SAP-archive / devops-cm-client

Simple command line interface to handle basic change management related actions via ODATA requests.
Apache License 2.0
36 stars 15 forks source link

WIP: Moving the CM Client's Docker file out of devops-docker-files #31

Closed 1084565 closed 4 years ago

1084565 commented 5 years ago

Just moving the Docker file and readme contents from the devops-docker-images repo to "where it really belongs". I chose the master branch, because the Dockerfile doesn't interfere with any existing content. Additionally I merged the readme description to accomodate the docker usage.

What's missing: once we merge this we should set up the build on Dockerhub.

marcusholl commented 5 years ago

I would like to suggest to put the docker file related items into an orphan branch.

Reason: the docker image is another artifact like the jar /tar.gz file. We are also using two different techologies (mvn build / docker build). I'm convinced it is more easy to handle with independent branches.

o-liver commented 5 years ago

Change the repo settings that you cannot merge without approval please.

1084565 commented 5 years ago

@marcusholl I prefer to have it in the same branch as the sources, its more transparent and visible that way. What do you think @o-liver @radsoulbeard @IKirilova @rodibrin

radsoulbeard commented 5 years ago

I have to agree with @marcusholl as we have here two deliverables with two live cycles. From master we release into maven central. The Docker image is built from the jar in maven central so is does not make any sense to put it in the same branch. I would agree to have it in the same branch in case of a multi stage built with a resulting Docker image only.

marcusholl commented 5 years ago

@1084565 I disagree. E.g. having tags means we tag always everything, cm-client as it and the docker image. Imaging we have to rebuild the docker image since the FROM version changed (e.g. security relevant updates). In this case also the jar/tar.gz gets a new tag. It is easier wrt handling if we use dedicated branches.

Basically we decided to divide the dev-ops-docker images in order to keep the images separated from the life-cycle point of view and here we do the oposite.