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 < > fne...@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/EnhancementProposals/Decision_record_T302863_toolforge_byoc > > > > -- > > 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/ -- David Caro SRE - Cloud Services Wikimedia Foundation <https://wikimediafoundation.org/> PGP Signature: 7180 83A2 AC8B 314F B4CE 1171 4071 C7E1 D262 69C3 "Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment."
signature.asc
Description: PGP signature
_______________________________________________ Cloud mailing list -- cloud@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/
