-
Notifications
You must be signed in to change notification settings - Fork 23
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
Correct dockerfiles to run the tests successfully again. split prepa… #103
Conversation
Based off of #101 Primary motivations:
|
setuptools \ | ||
virtualenv==16.0.0 \ | ||
pipenv==2018.11.26 \ | ||
pip==10.0.0 \ |
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.
required fix for breaking tests.
RUN : ${LIBINDY_VERSION:?"LIBINDY_VERSION must be provided"} | ||
ENV LIBINDY_VERSION=${LIBINDY_VERSION} | ||
|
||
RUN apt-get install -y \ |
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.
required fix for breaking tests.
ARG LIBINDY_VERSION | ||
ENV LIBINDY_REPO_COMPONENT=${LIBINDY_REPO_COMPONENT:-master} | ||
ENV LIBINDY_VERSION=${LIBINDY_VERSION:-1.10.0~1171} | ||
# sovrin repo init |
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.
allow greater degree of control over dockerfiles via env variables (the GHA for sovrin uses these, for example).
# Install environment | ||
RUN apt-get update -y && apt-get install -y \ | ||
git \ | ||
wget \ | ||
python3.5 \ |
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.
3.5 installed by default in xenial.
system/docker/node/Dockerfile
Outdated
ARG LIBINDY_CRYPTO_VERSION | ||
RUN : ${LIBINDY_CRYPTO_VERSION:?"LIBINDY_CRYPTO_VERSION must be provided"} |
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.
provides greater control and better error feedback when using env vars to control the test behaviour.
rm -rf /var/lib/apt/lists/*; \ | ||
COPY . . | ||
RUN if [ -n "$SOVRIN_INSTALL" ]; then \ | ||
dpkg -i "sovrin_${SOVRIN_VERSION}_amd64.deb"; \ |
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.
this is what installs the pending sovrin package in the GHA.
alternative would be to publish a dev sovrin deb every time a pull request is created, but not sure if that will be something the sovrin-foundation nexus would/should support @WadeBarnes
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.
The comment below says that we gonna cache both images, but can we cache the node image since it includes the built source?
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.
the github actions responsible for caching can cache based on a hash of changed files. The hash can include multiple file patterns. So if we want node to rebuild whenever the source changes, we could do something like
**/Dockerfile, **.*.py
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.
Ok, fine. I just think .py files will be changed in most commits so the cache can make the build process even slower in this case.
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.
But anyway, it's fine for the first version.
@@ -0,0 +1,87 @@ | |||
#!/bin/bash |
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.
as mentioned, splitting the above prepare script into these two components allow the GHA to build/cache the node and client docker images separately.
9801eca
to
0a4b695
Compare
@askolesov, @Toktar, Could you please review and merge? |
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.
Looks good. The only thought - we shouldn't cache node image since it includes the built sources. Probably we could split it into two images and cache the part without sources. Anyway, it's not about this repo and this PR.
&& rm -rf /var/lib/apt/lists/* | ||
|
||
# python | ||
ARG PYTHON3_VERSION | ||
ENV PYTHON3_VERSION=${PYTHON3_VERSION:-3.5} |
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.
Could you please tell why the python version is being removed here? Soon it is planned to migrate to ubuntu20.04 and this variable may be needed due to the fact that the version of python will not coincide with the default version.
Of course, this is only relevant for the case when this Dockerfile will be edited to create an image for ubuntu20.04, and not a new one will be created from scratch.
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.
Right, the idea was to remove this since 3.5 is installed by default on xenial. You are also correct that if this was bumped to 20.04 that would cause this dockerfile to use 3.8 by default.
I think in the ideal case we use 3.8 if possible anyways when this is moved to 20.04, since I don't think we want to use 3.5 with 20.04 as it is no longer supported. So I think even with the update to 20.04 we would prefer to use the default python installation that comes with 20.04. If for some reason we aren't able to move to 3.8 we could add this back.
Is it desirable for someone running the tests to be able to switch python versions on the fly? In my experience so far it seems like everything is running on 3.5 currently, and with the move to 20.04 it seems likely that everything will run on 3.8. Is there a need for these tests to be run on arbitrary versions of python? If so I should probably put this back
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.
Given that we are using the default versions on both systems, I think you are right. We can remove this variable.
I hope that we will write system tests for upgrading from Ubuntu 16.04 to Ubuntu 20.04 and there will be a change of python version on the fly, but the case is specific. Then we can return this variable if needed.
7654ad7
to
8d3f8ee
Compare
Could you please fix DCO sign for commit |
65282da
to
4f419d3
Compare
…e script to allow better caching. Signed-off-by: Devin Smith <devinleighsmith@gmail.com>
Signed-off-by: Devin Smith <devinleighsmith@gmail.com>
Signed-off-by: Devin Smith <devinleighsmith@gmail.com>
4f419d3
to
49ea681
Compare
Signed-off-by: Devin Smith <devinleighsmith@gmail.com>
b18b7aa
to
f58d8c8
Compare
@Toktar @askolesov I had to make a few updates to get 100% of the tests to pass, viewable here: https://github.com/devinleighsmith/sovrin/runs/2468937322?check_suite_focus=true should be good for approval now. |
@Toktar @askolesov, are you able to provide a final review, then approve and merge? |
…re script to allow better caching.
Signed-off-by: Devin Smith devinleighsmith@gmail.com