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

Kubernetes/Cluster deployment #105

Open
2 of 3 tasks
sk1p opened this issue Sep 4, 2018 · 5 comments
Open
2 of 3 tasks

Kubernetes/Cluster deployment #105

sk1p opened this issue Sep 4, 2018 · 5 comments
Labels
GSOC Google Summer of Code

Comments

@sk1p
Copy link
Member

sk1p commented Sep 4, 2018

See also #67 for auth related questions.

Edit: Removed HDFS aspects

@sk1p
Copy link
Member Author

sk1p commented Nov 19, 2018

For docker, see also: https://simonwillison.net/2018/Nov/19/smaller-python-docker-images/

@sk1p sk1p added this to To do in Cluster Deployment Jan 21, 2020
@uellue uellue added the GSOC Google Summer of Code label Jan 22, 2020
@irahulcse
Copy link
Contributor

irahulcse commented Feb 20, 2020

@sk1p
Copy link
Member Author

sk1p commented Feb 20, 2020

We would love to have a docker build and publish at the end of our CI pipeline. Currently, we are building (not publishing) a docker image as a step of the dist job, but in addition, we should publish it if all other jobs have succeeded, in the packaging stage (see .travis.yml).

I think using the automated building from docker hub means the docker image will be built independently from the CI fail/success status, right?

@irahulcse
Copy link
Contributor

irahulcse commented Feb 24, 2020

Yes, I also think so the docker hub build will be independent of CI fail/success status. Not quite sure about it but might we need to update the docker hub after every new build?.

@sk1p and @uellue I am moving forward with this https://docs.docker.com/docker-hub/builds/ and hope everything would be fine at the end.

@sk1p
Copy link
Member Author

sk1p commented Feb 25, 2020

Hmm, I'm not convinced that's the way to go. How do you prevent broken docker images from being pushed? If your answer is using autotest, how do you prevent having a completely separate test run from the rest of our pipeline? Feel free to play around with the build service, but you'll have to convince me to make it the official image 😁

On our road map, we have a migration to azure pipelines for CI, to consolidate our travis and appveyor builds into a single service. We already have the basics implemented in #565, it's mostly missing replacements for some travis specifics (basically travis-sphinx and updating the release script to migrate from the TRAVIS_* environment variables). Do you think that it may be possible to build the docker image from an azure pipeline job?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GSOC Google Summer of Code
Projects
Development

No branches or pull requests

3 participants