Repository navigation
Add Docker build argument to specify pip version and dh-virtualenv branch #102
Description
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.
Activity
arm4b commentedon 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, anddh-virtualenvbranch (?), we'll also need to pin thevirtualenvversion. What if we'll need to pin thesetuptoolsandwheel, 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.