Which version of golang does the toolforge build service currently support? Could it be upgraded to a recent version, such as go 1.23 or 1.24?
Somewhat related: Has it been considered to support building containers from a regular Dockerfile/Containerfile? From my personal perspective, I'm not sure if Heroku buildpacks give much value for all their complexity; if I could, I'd rather run "podman build" from a gitlab runner. But that's just my personal opinion as a user;. Surely this has been discussed before?
$ toolforge build start https://github.com/brawer/osmviews.git [step-build] 2025-04-23T12:53:03.061032884Z [Reading build configuration] [step-build] 2025-04-23T12:53:03.068120654Z Detected Go version requirement: =1.23 [step-build] 2025-04-23T12:53:03.068814689Z [step-build] 2025-04-23T12:53:03.068856285Z [Error: Heroku Go Buildpack version resolution error] [step-build] 2025-04-23T12:53:03.068870316Z Couldn't resolve go version for: =1.23 [step-build] 2025-04-23T12:53:03.070393300Z ERROR: failed to build: exit status 1
Many thanks,
— Sascha
On Wed, Apr 23, 2025 at 3:08 PM Sascha Brawer via Cloud cloud@lists.wikimedia.org wrote:
Which version of golang does the toolforge build service currently support? Could it be upgraded to a recent version, such as go 1.23 or 1.24?
Hi Sascha, we support the same versions supported by the upstream Heroku Go buildpack. [0] You should be able to use Go 1.23 or 1.24 by putting that version in go.mod. [1]
Somewhat related: Has it been considered to support building containers from a regular Dockerfile/Containerfile? From my personal perspective, I'm not sure if Heroku buildpacks give much value for all their complexity; if I could, I'd rather run "podman build" from a gitlab runner. But that's just my personal opinion as a user;. Surely this has been discussed before?
Yes, this was discussed a few times, but at the moment we have decided not to support this. [2] Using buildpacks gives us more control on the way the container images are built.
We understand that some users would prefer using Dockerfiles, but we also believe that buildpacks should be able to cover most or all use cases. If you have something that you are struggling to deploy with buildpacks, we always welcome bug reports and feature requests. :)
Francesco
[0] https://github.com/heroku/buildpacks-go [1] https://devcenter.heroku.com/articles/go-modules [2] https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/Enhancemen...
Hi Francesco,
You should be able to use Go 1.23 or 1.24 by putting that version in
go.mod. [1]
Hm, is the build service perhaps using an old version of Heroku's Go buildpack? According to the logs [below], it looks like it's still on heroku/go 0.1.13, whereas the current release [1] would be 0.5.8 [2]? Assuming I'm looking at the repo that is the upstream for Toolforge Build Service; not sure if that's the case.
$ toolforge build start https://github.com/brawer/osmviews.git
[step-detect] 2025-04-23T16:19:39.378722944Z 2 of 4 buildpacks participating [step-detect] 2025-04-23T16:19:39.378824612Z heroku/go 0.1.13 [step-detect] 2025-04-23T16:19:39.378846748Z heroku/procfile 2.0.2 [step-restore] 2025-04-23T16:19:27.438843274Z 2025/04/23 16:19:27 warning: unsuccessful cred copy: ".docker" from "/tekton/creds" to "/tekton/home": unable to open destination: open /tekton/home/.docker/config.json: permission denied [step-build] 2025-04-23T16:19:39.927624509Z [step-build] 2025-04-23T16:19:39.927733310Z [Reading build configuration] [step-build] 2025-04-23T16:19:39.936762188Z Detected Go version requirement: =1.24.2 [step-build] 2025-04-23T16:19:39.938055432Z [step-build] 2025-04-23T16:19:39.938089303Z [Error: Heroku Go Buildpack version resolution error] [step-build] 2025-04-23T16:19:39.938099399Z Couldn't resolve go version for: =1.24.2 [step-build] 2025-04-23T16:19:39.940494876Z ERROR: failed to build: exit status 1
[1] https://github.com/heroku/buildpacks-go/releases [2] https://github.com/heroku/buildpacks-go/releases/tag/v0.5.8
Anyhow, thanks so much for your help! Best,
— Sascha
Am Mi., 23. Apr. 2025 um 15:55 Uhr schrieb Francesco Negri < fnegri@wikimedia.org>:
On Wed, Apr 23, 2025 at 3:08 PM Sascha Brawer via Cloud cloud@lists.wikimedia.org wrote:
Which version of golang does the toolforge build service currently
support? Could it be upgraded to a recent version, such as go 1.23 or 1.24?
Hi Sascha, we support the same versions supported by the upstream Heroku Go buildpack. [0] You should be able to use Go 1.23 or 1.24 by putting that version in go.mod. [1]
Somewhat related: Has it been considered to support building containers
from a regular Dockerfile/Containerfile? From my personal perspective, I'm not sure if Heroku buildpacks give much value for all their complexity; if I could, I'd rather run "podman build" from a gitlab runner. But that's just my personal opinion as a user;. Surely this has been discussed before?
Yes, this was discussed a few times, but at the moment we have decided not to support this. [2] Using buildpacks gives us more control on the way the container images are built.
We understand that some users would prefer using Dockerfiles, but we also believe that buildpacks should be able to cover most or all use cases. If you have something that you are struggling to deploy with buildpacks, we always welcome bug reports and feature requests. :)
Francesco
[0] https://github.com/heroku/buildpacks-go [1] https://devcenter.heroku.com/articles/go-modules [2] https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/Enhancemen...
-- Francesco Negri (he/him) -- IRC: dhinus Site Reliability Engineer, Cloud Services team Wikimedia Foundation
Yes, we are using an old version of the buildpack, there's work on updating it to the latest [1], that will allow you to try the newer buildpacks/runner images using `--use-latest-versions` that eventually will become the default.
And yep, with the newer buildpacks your code builds ok, from my toolforge dev environment with the patches in the task applied: """ $ toolforge build start https://github.com/brawer/osmviews --use-latest-versions ... [step-build] 2025-04-23T16:34:54.230639291Z [Reading build configuration] [step-build] 2025-04-23T16:34:54.444234528Z Detected Go version requirement: =1.24.2 [step-build] 2025-04-23T16:34:54.444266547Z Resolved Go version: go1.24.2 (linux-amd64) [step-build] 2025-04-23T16:34:54.444271442Z [step-build] 2025-04-23T16:34:54.444273579Z [Installing Go distribution] [step-build] 2025-04-23T16:34:54.444435335Z Installing go1.24.2 (linux-amd64) from https://go.dev/dl/go1.24.2.linux-amd64.tar.gz [step-build] 2025-04-23T16:34:58.644701124Z ... [step-results] 2025-04-23T16:35:35.230389815Z Built image 192.168.5.15/tool-tf-test/tool-tf-test:latest@sha256:818574fc1191eac0b51e6130a6c5c8ef0ed9e7d3464ada5473ed2d839d68b59b """
The 1.24 support was added in 0.5.4 release of the buildpack [2], should not be hard to hack it in, but I think we are close enough to allowing the newer runner/buildpacks to go that route instead. Let us know if it's something really really urgent.
[1] https://phabricator.wikimedia.org/T380127 [2] https://github.com/heroku/buildpacks-go/compare/v0.5.3...v0.5.4
On 04/23 18:26, Sascha Brawer via Cloud wrote:
Hi Francesco,
You should be able to use Go 1.23 or 1.24 by putting that version in
go.mod. [1]
Hm, is the build service perhaps using an old version of Heroku's Go buildpack? According to the logs [below], it looks like it's still on heroku/go 0.1.13, whereas the current release [1] would be 0.5.8 [2]? Assuming I'm looking at the repo that is the upstream for Toolforge Build Service; not sure if that's the case.
$ toolforge build start https://github.com/brawer/osmviews.git
[step-detect] 2025-04-23T16:19:39.378722944Z 2 of 4 buildpacks participating [step-detect] 2025-04-23T16:19:39.378824612Z heroku/go 0.1.13 [step-detect] 2025-04-23T16:19:39.378846748Z heroku/procfile 2.0.2 [step-restore] 2025-04-23T16:19:27.438843274Z 2025/04/23 16:19:27 warning: unsuccessful cred copy: ".docker" from "/tekton/creds" to "/tekton/home": unable to open destination: open /tekton/home/.docker/config.json: permission denied [step-build] 2025-04-23T16:19:39.927624509Z [step-build] 2025-04-23T16:19:39.927733310Z [Reading build configuration] [step-build] 2025-04-23T16:19:39.936762188Z Detected Go version requirement: =1.24.2 [step-build] 2025-04-23T16:19:39.938055432Z [step-build] 2025-04-23T16:19:39.938089303Z [Error: Heroku Go Buildpack version resolution error] [step-build] 2025-04-23T16:19:39.938099399Z Couldn't resolve go version for: =1.24.2 [step-build] 2025-04-23T16:19:39.940494876Z ERROR: failed to build: exit status 1
[1] https://github.com/heroku/buildpacks-go/releases [2] https://github.com/heroku/buildpacks-go/releases/tag/v0.5.8
Anyhow, thanks so much for your help! Best,
— Sascha
Am Mi., 23. Apr. 2025 um 15:55 Uhr schrieb Francesco Negri < fnegri@wikimedia.org>:
On Wed, Apr 23, 2025 at 3:08 PM Sascha Brawer via Cloud cloud@lists.wikimedia.org wrote:
Which version of golang does the toolforge build service currently
support? Could it be upgraded to a recent version, such as go 1.23 or 1.24?
Hi Sascha, we support the same versions supported by the upstream Heroku Go buildpack. [0] You should be able to use Go 1.23 or 1.24 by putting that version in go.mod. [1]
Somewhat related: Has it been considered to support building containers
from a regular Dockerfile/Containerfile? From my personal perspective, I'm not sure if Heroku buildpacks give much value for all their complexity; if I could, I'd rather run "podman build" from a gitlab runner. But that's just my personal opinion as a user;. Surely this has been discussed before?
Yes, this was discussed a few times, but at the moment we have decided not to support this. [2] Using buildpacks gives us more control on the way the container images are built.
We understand that some users would prefer using Dockerfiles, but we also believe that buildpacks should be able to cover most or all use cases. If you have something that you are struggling to deploy with buildpacks, we always welcome bug reports and feature requests. :)
Francesco
[0] https://github.com/heroku/buildpacks-go [1] https://devcenter.heroku.com/articles/go-modules [2] https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/Enhancemen...
-- Francesco Negri (he/him) -- IRC: dhinus Site Reliability Engineer, Cloud Services team Wikimedia Foundation
Cloud mailing list -- cloud@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/