-
Notifications
You must be signed in to change notification settings - Fork 139
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
Bazel CI Release Process should build and publish Bazel docker containers #1060
Comments
@philwo Hello, any news here? This is still blocking us on smoothly upgrading Bazel past 3.5. |
@kevingessner Not yet, sorry :( But this is really important to me and I'll get to it as soon as I can, promised! |
Any updates on this? |
I'm all for automating this, but for now can we get a manually built image pushed |
Friendly bump, blocking upgrade from 3.5.0 |
Apparently there are no official bazel docker images for v3.5.0+ Ref: bazelbuild/continuous-integration#1060
* Update bazel and various rules and dependencies * Drop to v3.5.0 again Apparently there are no official bazel docker images for v3.5.0+ Ref: bazelbuild/continuous-integration#1060 * Gazelle * Sum * Run go mod tidy after gazelle repos update
This is still an issue. |
Meanwhile, updating the readme with instructions to build it manually would also help! |
I came across this issue while searching for a docker image that supported bazel 4. I didn't find any, so I made my own and thought I would share. # Dockerfile
FROM registry.fedoraproject.org/fedora:34
RUN dnf install -y dnf-plugins-core git patch python3 && \
dnf copr enable -y vbatts/bazel && \
dnf install -y bazel4 && \
dnf clean all && \
rm -rf /var/cache/yum
RUN ln -s /usr/bin/python3 /usr/bin/python
WORKDIR /home/builder
ENTRYPOINT ["bazel"] $ docker build .
...
Successfully built <container-id>
$ docker run <container-id> --version
bazel 4.2.1 |
@philwo This is actually more critical than ever. The base image used to build the latest container is using ubuntu 16.04 which as of April 30th is now EOL. This is a security issue now. I've also experienced CA failures due to the wildly out of date base image. |
It has been almost a year. Seems a bit long for a P1? Should it be now bumped to P0 to help prioritization? I came here after updating |
Any updates here? |
This is kind of a hack to upgrade bazel to 4.2.1. When a new Bazel Docker container is released we should remove this commit, and upgrade the docker container instead. See bazelbuild/continuous-integration#1060
@ScarletFlash I'm not on or affiliated with the Bazel team, but I reached out to one of my contacts inside Google to help get this prioritized. |
This is kind of a hack to upgrade bazel to 4.2.1. When a new Bazel Docker container is released we should remove this commit, and upgrade the docker container instead. See bazelbuild/continuous-integration#1060
I talked with @alexeagle about this last week who wanted to help me out (thanks!!). Alex, do you already have a Dockerfile that I could try? |
This is necessary because the new rules_go and gazelle versions require a version of bazel newer than what's in the GCR docker image pre-built by the bazel team. Apparently, they stopped building those in 2020. bazelbuild/continuous-integration#1060 Signed-off-by: Chris Koch <chrisko@google.com>
This is necessary because the new rules_go and gazelle versions require a version of bazel newer than what's in the GCR docker image pre-built by the bazel team. Apparently, they stopped building those in 2020. bazelbuild/continuous-integration#1060 Signed-off-by: Chris Koch <chrisko@google.com>
This is necessary because the new rules_go and gazelle versions require a version of bazel newer than what's in the GCR docker image pre-built by the bazel team. Apparently, they stopped building those in 2020. bazelbuild/continuous-integration#1060 Signed-off-by: Chris Koch <chrisko@google.com>
This is necessary because the new rules_go and gazelle versions require a version of bazel newer than what's in the GCR docker image pre-built by the bazel team. Apparently, they stopped building those in 2020. bazelbuild/continuous-integration#1060 Signed-off-by: Chris Koch <chrisko@google.com>
This can be a nice feature when a .tex file contains a tikz figure. This is enabled by exposing the dvisvgm binary in the defined latex texlive toolchan. dvisvgm is dependent on ghostscript as a dynamic lib, which is why it has been added. The previously referenced bazel docker image in cirrus.yaml was not actively updated by google. The last supported version was 3.5. So the docker image was changed to the newly provided image. See: bazelbuild/continuous-integration#1060 bazelbuild/continuous-integration#1401 ghostscript is built from source using rules_foreign_cc, which can't be entirely bootstrapped at this point. (It can't build autoconf) So it needs that to be installed from e.g. apt. The bazel docker container did as far as I investigated not allow to install packages in the container, I could be wrong though. Instead I created a github workflow, which depends on bazelisk. bazelisk is a downloader for bazel. You can configure it always run with a specific version. But sense cirrus.yaml uses latest, we don't state any version meaning it will always download the latest bazel. It also enables a bazel cache which "should" speed up execution in the ci pipeline.
This can be a nice feature when a .tex file contains a tikz figure. This is enabled by exposing the dvisvgm binary in the defined latex texlive toolchan. dvisvgm is dependent on ghostscript as a dynamic lib, which is why it has been added. The previously referenced bazel docker image in cirrus.yaml was not actively updated by google. The last supported version was 3.5. So the docker image was changed to the newly provided image. See: bazelbuild/continuous-integration#1060 bazelbuild/continuous-integration#1401 ghostscript is built from source using rules_foreign_cc, which can't be entirely bootstrapped at this point. (It can't build autoconf) So it needs that to be installed from e.g. apt. The bazel docker container did as far as I investigated not allow to install packages in the container, I could be wrong though. Instead I created a github workflow, which depends on bazelisk. bazelisk is a downloader for bazel. You can configure it always run with a specific version. But sense cirrus.yaml uses latest, we don't state any version meaning it will always download the latest bazel. It also enables a bazel cache which "should" speed up execution in the ci pipeline.
This can be a nice feature when a .tex file contains a tikz figure. This is enabled by exposing the dvisvgm binary in the defined latex texlive toolchan. dvisvgm is dependent on ghostscript as a dynamic lib, which is why it has been added. The previously referenced bazel docker image in cirrus.yaml was not actively updated by google. The last supported version was 3.5. So the docker image was changed to the newly provided image. See: bazelbuild/continuous-integration#1060 bazelbuild/continuous-integration#1401 ghostscript is built from source using rules_foreign_cc, which can't be entirely bootstrapped at this point. (It can't build autoconf) So it needs that to be installed from e.g. apt. The bazel docker container did as far as I investigated not allow to install packages in the container, I could be wrong though. Instead I created a github workflow, which depends on bazelisk. bazelisk is a downloader for bazel. You can configure it always run with a specific version. But sense cirrus.yaml uses latest, we don't state any version meaning it will always download the latest bazel. It also enables a bazel cache which "should" speed up execution in the ci pipeline.
This can be a nice feature when a .tex file contains a tikz figure. This is enabled by exposing the dvisvgm binary in the defined latex texlive toolchan. dvisvgm is dependent on ghostscript as a dynamic lib, which is why it has been added. The previously referenced bazel docker image in cirrus.yaml was not actively updated by google. The last supported version was 3.5. So the docker image was changed to the newly provided image. See: bazelbuild/continuous-integration#1060 bazelbuild/continuous-integration#1401 ghostscript is built from source using rules_foreign_cc, which can't be entirely bootstrapped at this point. (It can't build autoconf) So it needs that to be installed from e.g. apt. The bazel docker container did as far as I investigated not allow to install packages in the container, I could be wrong though. Instead I created a github workflow, which depends on bazelisk. bazelisk is a downloader for bazel. You can configure it always run with a specific version. But sense cirrus.yaml uses latest, we don't state any version meaning it will always download the latest bazel. It also enables a bazel cache which "should" speed up execution in the ci pipeline.
This can be a nice feature when a .tex file contains a tikz figure. svg generation is enabled by exposing the dvisvgm binary in the defined latex texlive toolchan. dvisvgm in turn, is dependent on ghostscript as a dynamic lib, which is why it has been added. ghostscript is built from source with rules_foreign_cc. The previously referenced bazel docker image in cirrus.yaml was not actively updated by google. The last supported version was 3.5. This resulted in @platforms, needed by rules_foreign_cc, not being available. So the docker image was changed to the newly provided image. See: bazelbuild/continuous-integration#1060 bazelbuild/continuous-integration#1401 rules_foreign_cc can't be entirely bootstrapped at this point. (It can't build autoconf) So rules_foreign_cc needs autoconf to be installed from e.g. apt. The bazel docker container, did as far as I investigated, not allow to install packages in the container, I could be wrong though. Instead I created a github workflow, which depends on bazelisk. bazelisk is a downloader for bazel. You can configure it to always run with a specific version. But sense cirrus.yaml uses latest, we don't state any version meaning it will always download the latest bazel. It also enables a bazel cache which "should" speed up execution in the ci pipeline.
This can be a nice feature when a .tex file contains a tikz figure. svg generation is enabled by exposing the dvisvgm binary in the defined latex texlive toolchan. dvisvgm in turn, is dependent on ghostscript as a dynamic lib, which is why it has been added. ghostscript is built from source with rules_foreign_cc. The previously referenced bazel docker image in cirrus.yaml was not actively updated by google. The last supported version was 3.5. This resulted in @platforms, needed by rules_foreign_cc, not being available. So the docker image was changed to the newly provided image. See: bazelbuild/continuous-integration#1060 bazelbuild/continuous-integration#1401 rules_foreign_cc can't be entirely bootstrapped at this point. (It can't build autoconf) So rules_foreign_cc needs autoconf to be installed from e.g. apt. The bazel docker container, did as far as I investigated, not allow to install packages in the container, I could be wrong though. Instead I created a github workflow, which depends on bazelisk. bazelisk is a downloader for bazel. You can configure it to always run with a specific version. But sense cirrus.yaml uses latest, we don't state any version meaning it will always download the latest bazel. It also enables a bazel cache which "should" speed up execution in the ci pipeline.
Potential workaround is to use the cockroach db bazel images https://hub.docker.com/r/cockroachdb/bazel/tags |
Hey - we have bazel images published by Chainguard here at cgr.dev/chainguard/bazel! Feel free to try them out. |
I'm closing this one since bazel docker images are already published to gcr.io/bazel-public/bazel for every new Bazel version |
@meteorcloudy could/should that info be added to the bazel docs? it is not very discoverable. |
@yogurtearl SGTM, sent bazelbuild/bazel#17113 We also have documentation in our release process: https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md#push-new-docker-image |
Fixes bazelbuild/continuous-integration#1060 (comment) Closes #17113. PiperOrigin-RevId: 511666892 Change-Id: Ifbfb8c9b2ba82724719101a0118f1235948f6bab
This is kind of a hack to upgrade bazel to 4.2.1. When a new Bazel Docker container is released we should remove this commit, and upgrade the docker container instead. See bazelbuild/continuous-integration#1060
It's nice to be able to find the Dockerfile for any image easily, so I'm just adding the link to the "Getting Started with Bazel Docker Container" doc. Maybe it was probably me not knowing how to navigate the Container Registry website but I couldn't find the Dockerfile for the official images. In fact, it was a bit confusing because, while googling, I did find some old versions of the website that pointed to an old registry with very old images! Luckily, trying to find what was going on, I found [bazelbuild/continuous-integration issue bazelbuild#1060](bazelbuild/continuous-integration#1060) and from there, I found the Dockerfile for the official image.
It's nice to be able to find the Dockerfile for any image easily, so I'm just adding the link to the "Getting Started with Bazel Docker Container" doc. Maybe it was probably me not knowing how to navigate the Container Registry website but I couldn't find the Dockerfile for the official images. In fact, it was a bit confusing because, while googling, I did find some old versions of the website that pointed to an old registry with very old images! Luckily, trying to find what was going on, I found [bazelbuild/continuous-integration issue bazelbuild#1060](bazelbuild/continuous-integration#1060) and from there, I found the Dockerfile for the official image.
It's nice to be able to find the Dockerfile for any image easily, so I'm just adding the link to the "Getting Started with Bazel Docker Container" doc. Maybe it was probably me not knowing how to navigate the Container Registry website but I couldn't find the Dockerfile for the official images. In fact, it was a bit confusing because, while googling, I did find some old versions of the website that pointed to an old registry with very old images! Luckily, trying to find what was going on, I found [bazelbuild/continuous-integration issue #1060](bazelbuild/continuous-integration#1060) and from there, I found the Dockerfile for the official image. Closes #23072. PiperOrigin-RevId: 662079926 Change-Id: I54f6e7cc0ef74540ea3330248130e96941477322
The current Bazel Docker containers are being built by the RBE toolchains team, but they asked us to take this on.
We should setup some tooling and a pipeline (?) to regularly automatically build current Bazel containers for all released versions.
The text was updated successfully, but these errors were encountered: