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

Add Docker build argument to specify pip version and dh-virtualenv branch #102

Open
blag opened this issue Feb 4, 2021 · 1 comment
Open

Comments

@blag
Copy link
Contributor

blag commented Feb 4, 2021

In st2/Makefile we do a neat trick to grab the version of virtualenv to install from the requirements.txt file instead of specifying the version in multiple places.

We could do a similar thing in our Dockerfiles to specify the version of pip, pulling it from st2/Makefile via a well crafted curl/grep/sed command. In such a case, when it comes time to update the version of pip, we could add a build argument to Dockerfiles that specifies the branch of ST2 to pull from.

Alternatively, we could just add a build argument that directly specifies the version of pip to pull, but that still requires us to update the default version every time we rev pip.

We could also add build arguments to specify the branch of dh-virtualenv, just in case we need to make any more changes to our fork.

Opening this issue to start the discussion, and keep track of progress.

@arm4b
Copy link
Member

arm4b commented Feb 5, 2021

Yeah, It's about Pros/Cons tradeoff as usual.

While the improved level of automation, there's already high amount of indirection and moving pieces in the packaging process.
Trying to dynamically pull/install version of pip based on some upstream line of code would break the build repeatability. E.g. re-starting the build that happened half of the year ago should provide the same results, hence I'd prefer an explicit version pinning.

If we add Makefile + build args, besides of pip, and dh-virtualenv branch (?), we'll also need to pin the virtualenv version. What if we'll need to pin the setuptools and wheel, as it was required before?

With the new Makefile, CI would need a replacement too: from Docker Hub CI/CD (which is simple and configured via Dockerfile paths) to CircleCI or GH Actions. Change of CI will make the builds faster, but may be affected by the build failures due to Docker Hub rate-limiting. I see how we can summon more demons from the CI rework.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants