You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
In
st2/Makefile
we do a neat trick to grab the version of virtualenv to install from therequirements.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.
The text was updated successfully, but these errors were encountered: