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

Upgrades python version for cqlsh #4709

Merged
merged 2 commits into from
Jan 24, 2022
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 5 additions & 2 deletions Dockerfile
Original file line number Diff line number Diff line change
Expand Up @@ -94,11 +94,14 @@ CMD /start-cadence.sh
# All-in-one Cadence server
FROM cadence-server AS cadence-auto-setup

RUN apk add --update --no-cache ca-certificates py-pip mysql-client
RUN pip install cqlsh
RUN apk add --update --no-cache ca-certificates py-pip mysql-client python3
Groxx marked this conversation as resolved.
Show resolved Hide resolved
RUN pip3 install cqlsh

COPY docker/start.sh /start.sh

# test installed applications
RUN cqlsh --version
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

after testing this wouldn't have actually caught the cqlsh issue, which fails at runtime only when executing, but it would have caught other issues, such as failure to correctly install to path.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe pip3 install cqlsh && cqlsh --version so we don't make another layer?
but probably not a bad idea, since the install is far from a guarantee with python.

I suppose it's somewhat odd that there's no support for testing builds in dockerfiles 🤔

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 think normally you treat them as build artifacts and subject them to e2e testing as you would any other deployable

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, though in-dockerfile would let you test things as you build rather than only at the end. e.g. for from scratch things, you could test in a build-and-debug-friendly env before you copy the binaries to a minimal image.


CMD /start.sh


Expand Down