Closed chuck-confluent closed 3 years ago
Hey Chuck ! Thanks for the advices:
This is my current gitpod.yml:
tasks:
- init: |
cd environment/plaintext && ./start.sh; ./stop.sh
- command: |
echo "nothing to do"
ports:
- port: 9021
onOpen: open-browser
vscode:
extensions:
- ms-azuretools.vscode-docker
in the before part of the task, run the utils.sh script to set container image tags and then docker-compose pull some images
So I'm starting the most common environment plaintext
so that all main images are pulled (zookeeper, connect, broker etc..)
run start.sh in the command part of the task rather than init so that it runs indefinitely on launch
I don't really want to start something because when the user connects, he will choose one test to run, and in any case, the existing processes will be stopped because I always stop existing containers before starting a test. It's different from the Kafka-tutorials use case I believe
install necessary stuff like the confluent CLI to the workspace, again in the before part of the task. Imagine the workspace is the user's laptop. Put all the prerequisites on there.
The playground is made so that the only requirement is to have docker installed, for all other things I use docker images. So for example for az CLI, I'm using a docker image, etc..
There is one exception for this, it's ccloud
, and I will add it.
Thanks !
Looks like you already added the prebuild!
I left a comment on the commit that I think anything you want to have only in the prebuild step needs to be in init
rather than before
(I was wrong earlier). The before
will run on launch every time for users. Here is a picture from the gitpod docs that I found useful: https://www.gitpod.io/docs/config-start-tasks#prebuild-and-new-workspaces.
Thanks as always for your amazing work on stuff like this!
Btw I've never seen anything quite like how you use utils.sh to namespace CLI tools with docker (e.g. az
, jq
). That's pretty neat! It gives you a lot of control over the behavior of the playground to minimize dependency issues. Nice!
So I'm starting the most common environment plaintext so that all main images are pulled (zookeeper, connect, broker etc..)
Could you do docker-compose pull
instead? Or is there another reason to actually run the start and stop scripts?
Like this do you think ?
tasks:
- name: Install ccloud CLI and run environment/plaintext to download main docker images
init: |
curl -L --http1.1 https://cnfl.io/ccloud-cli | sudo sh -s -- -b /usr/local/bin
cd environment/plaintext && ./start.sh; ./stop.sh
Yes I can check for docker-compose pull instead
I would just change the start and stop to docker-compose pull
if the purpose is just to pull the images.
Since you're doing prebuilds, it might be handy to just have a function to pull all docker images referenced in the repo. That might be more of a maintenance burden than you'd like, since you might add and subtract different images at any time.
Hey Chuck,
I think I have now Prebuild working following your advices.
I tried to download every single docker image in the Prebuild, but I think it is overkill and will be bad for UX as whenever there would be a push to the repo (and I do a lot !), it will execute Prebuild and if someone tries to use the workspace, he will get this:
Unless I'm missing something ?
totally reasonable! feel free to close this issue if you like where it's at
Yay for adding gitpod! Here are a couple of suggested improvements to the user experience using gitpod prebuilds:
before
part of the task, run the utils.sh script to set container image tags and then docker-compose pull some imagescommand
part of the task rather thaninit
so that it runs indefinitely on launchbefore
part of the task. Imagine the workspace is the user's laptop. Put all the prerequisites on there.Happy GitPoding!