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

Correct dockerfiles to run the tests successfully again. split prepa… #103

Merged
merged 4 commits into from
May 12, 2021

Conversation

devinleighsmith
Copy link
Contributor

…re script to allow better caching.

Signed-off-by: Devin Smith devinleighsmith@gmail.com

@devinleighsmith
Copy link
Contributor Author

Based off of #101

Primary motivations:

  1. fix issues preventing existing tests from running.
  2. split prepare script up to allow created dockerfiles to be individually cached.
  3. update sovrin dependency to allow it to be installed via the GHA within the sovrin repo (by default sovrin is not required in these tests).

setuptools \
virtualenv==16.0.0 \
pipenv==2018.11.26 \
pip==10.0.0 \
Copy link
Contributor Author

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 \
Copy link
Contributor Author

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
Copy link
Contributor Author

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 \
Copy link
Contributor Author

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.

ARG LIBINDY_CRYPTO_VERSION
RUN : ${LIBINDY_CRYPTO_VERSION:?"LIBINDY_CRYPTO_VERSION must be provided"}
Copy link
Contributor Author

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"; \
Copy link
Contributor Author

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

Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Contributor

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
Copy link
Contributor Author

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.

@WadeBarnes
Copy link
Member

@askolesov, @Toktar, Could you please review and merge?

askolesov
askolesov previously approved these changes Apr 28, 2021
Copy link
Contributor

@askolesov askolesov left a 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}
Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

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.

@Toktar
Copy link
Contributor

Toktar commented Apr 29, 2021

Could you please fix DCO sign for commit 9f1d91f and resolve conflicts.
Changes look excellent. I'll approve them after fixes.

@devinleighsmith devinleighsmith force-pushed the test_fix branch 3 times, most recently from 65282da to 4f419d3 Compare April 29, 2021 15:40
…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>
Signed-off-by: Devin Smith <devinleighsmith@gmail.com>
@devinleighsmith
Copy link
Contributor Author

@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.

@WadeBarnes
Copy link
Member

@Toktar @askolesov, are you able to provide a final review, then approve and merge?

@Toktar Toktar merged commit 11e8f96 into hyperledger:master May 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants