serviced-isvcs is the docker image containing the majority of the Internal Services used by Control Center.
To buid a dev image for testing locally, use
git checkout develop
git pull origin develop
make clean build
The result should be a vN-dev
image in your local docker repo (e.g. v73-dev
). If you need to make changes, create
a feature branch like you would for any other kind of change, modify the image definition as necessary, use make clean build
to
build an image and then test it as necessary. Once you have finished your local testing, commit your changes, push them,
and create a pull-request as you would normally. A Jenkins PR build will be started to verify that your changes will build in
a Jenkins environment.
NOTE: To test changes of this image with Control Center, you will have to update a
GO language constant in the serviced source code to reference the new image tag; e.g.
IMAGE_TAG
The following is a general procedure for updating a local build of the isvc image to verfiy that a new component version works as expected with Control Center. Note that you should NOT need to change the isvc version at this time. The vN-dev
value of the image on the develop branch should always be the next available version. For instance, if the latest serviced code is using the published image v58
, then the value on the develop
branch of this repo should be v59-dev
, and that is the version you should use for local testing.
make clean build
in serviced-isvcs to build a local, vN-dev
copy of the isvc image.IMAGE_TAG
in isvcs/isvcs.go
to use the vN-dev
image you just builtvN-dev
version.Use git flow to release a new version to the master
branch.
The image version is defined in the makefile.
For Zenoss employees, the details on using git-flow to release a version is documented on the Zenoss Engineering web site. After the git flow process is complete, a jenkins job can be triggered manually to build and publish the image to docker hub. See http://platform-jenkins.zenoss.eng/job/images/job/serviced-isvcs/job/serviced-isvcs-master/
Note that once the git flow release process is done, the makefile on develop should specify the next vN-dev
value. For instance, if image tag is v74-dev
when you start the release process, then you will release v74
to master, and the next version on develop at the end of process should be v75-dev
.
After the version is published to docker hub: