-
Notifications
You must be signed in to change notification settings - Fork 706
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Turn release.py into a binary to build the artifacts for all the different contexts #133
Conversation
…erent modes. * We have multiple contexts in which we want to build the images and other artifacts * local * Tests * releases * This CL changes release.py so handle all three cases. * This increases code reuse and provides greater consistency. * Prior to this CL building the operator image didn't build other artifacts; notably the helm package. * This change is intended to facilitate transitioning to a workflow system for running more complex test and release workflows. * Currently the test infrastructure is using runner.py to build the images. The tests don't actually build the helm package. * We want to replace runner.py with a binary (release.py) that can be invoked to build the artifacts. This way our test/release workflow can just invoke that binary.
mkdir -p ${GOPATH}/src/github.com/jlewi | ||
ln -sf ${GIT_TRAINING} ${GOPATH}/src/mlkube.io | ||
mkdir -p ${GOPATH}/src/github.com/tensorflow | ||
ln -sf ${GIT_TRAINING} ${GOPATH}/src/github.com/tensorflow/k8s |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like ${GIT_TRAINING}
is the same as ${GOPATH}/src/github.com/tensorflow/k8s
in some case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand the question. Its certainly possible to check out the repository directly into your GOLANG src tree in which case you don't need to create a symbolic link.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe try using Makefile?
@jimexist I don't like writing complex make files. If we need a more complex build system I'm more inclined to switch to using bazel. I think the approach of using python scripts should be compatible with bazel because we can create custom build rules that would build tools and then use those tools. |
We have multiple contexts in which we want to build the images and other artifacts
* local
* Tests
* releases
This CL changes release.py so handle all three cases.
notably the helm package.
This change is intended to facilitate transitioning to a workflow system
for running more complex test and release workflows.
images. The tests don't actually build the helm package.
be invoked to build the artifacts. This way our test/release workflow
can just invoke that binary.