Skip to content
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

Merged
merged 4 commits into from
Nov 14, 2017

Conversation

jlewi
Copy link
Contributor

@jlewi jlewi commented Nov 9, 2017

  • 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.

…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
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

@jimexist jimexist left a 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?

@jlewi jlewi changed the title Turn release.py into a binary to build the artifacts for all the diff… Turn release.py into a binary to build the artifacts for all the different contexts Nov 14, 2017
@jlewi
Copy link
Contributor Author

jlewi commented Nov 14, 2017

@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.

@jlewi jlewi merged commit f27b8de into kubeflow:master Nov 14, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants