-
Notifications
You must be signed in to change notification settings - Fork 373
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
feat: Add Dockerfile that installs cody from source #7513
Conversation
This is just so that we have a reference here for now. We're unblocking a customer while we integrate a CI pipeline that will publish this whenever an agent release goes out. That means coping the _built_ files into this container, rather than using npm. We'll also need to give the GHA the creds to publish this to Dockerhub. I have chosen not to publish this image given it doesn't currently exist in the Sourcegraph Dockerhub registry. If the customer demands it, I could.
Finally got a fully working, locally built docker container that does not depend on `npm`. Had to add a .dockerignore so that it won't include `node_modules` when building, and also removed `.git` files. I only tested this manually by running `docker run --rm cody-cli cody help` which does display the help files correctly. There's some built in testing when creating the docker container (`which cody`, etc) so we know it doesn't build broken images. I decided against using `pnpm link -g` since it requires a bunch of setup and configuration, and instead created a shell script that calls node on the built js files, and added that to the path
f655fff
to
38d56ef
Compare
I'm not too familiar with how the CLI is built and released, @olafurpg would you know more? |
The CLI is effectively distributed the same way as the JB plugin. Or put differently, the JB plugin effectively embeds Cody CLI. It's a Node.js script with some required dependencies that we vendor with the npm package. Any concrete question you had in mind? |
@Chickensoupwithrice Are the CI failures okay in this context or something that is failing with the image? |
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.
Similar question about using wolfi, but not blocking
The CI failures are totally unrelated to the image, I'm not sure why, but they seem to fail pretty consistently? |
Switched to using Alpine for the container that runs the cody-cli
Alright, it's built and running on Alpine :) |
Slack context
Linear ticket
This is just so that we have a reference here for now. We're unblockinga customer while we integrate a CI pipeline that will publish this
whenever an agent release goes out. That means coping the built files
into this container, rather than using npm. We'll also need to give the
GHA the creds to publish this to Dockerhub.
This handles creation of a docker container, pushed to docker hub, which comes pre-installed with the cody npm package, built from source. Previously a single image was published for a customer under the
ccsourcegraph
account, but this PR makes the process production ready, and hooks into existing CI actions, under thesourcegraph
dockerhub account.I have chosen not to publish this image given it doesn't currently existin the Sourcegraph Dockerhub registry. If the customer demands it, I
could.
Once approved and merged, I'll publish the specific image for
5.5.17
to dockerhub since that CI run has already passed.Running
docker build . -t sourcegraph/cody-cli:5.5.17
from thecody/cli
directory will give you a container that hascody
installed.Test plan