We are a few versions behind on https://github.com/heroku/buildpacks-go, but I don't see anything in the commits or CHANGELOG that looks directly Procfile related. The latest tagged release also may not be compatible with pack (https://github.com/heroku/buildpacks-go/commit/111bb19806bb838c457ef1778a30487dc50f1cb0).

Adding tiny shell wrappers for the Procfile to call seems to work around the issue.

bd808 opened https://gitlab.wikimedia.org/toolforge-repos/bridgebot/-/merge_requests/1

Fix issues found during live testing of initial implementation

bd808 merged https://gitlab.wikimedia.org/toolforge-repos/bridgebot/-/merge_requests/1

Fix issues found during live testing of initial implementation

The procfile endpoints don't allow any new arguments if they have any already, this is an upstream issue on the procfile buildpack (T356016: [builds-builder,jobs-api,upstream] Calling nontrivial Procfile commands with arguments results in confusing error (“no such file or directory”)).
There's a note and a workaround in https://wikitech.wikimedia.org/wiki/Help:Toolforge/Build_Service#Procfile (feel free to reword if you find it not clear there).

For the bridgebot entry itself, the issue is that the golang buildpack generates on the fly the bridgebot procfile entry already:

dcaro@urcuchillay$ podman run --entrypoint bash --rm -ti tools-harbor.wmcloud.org/tool-bridgebot/tool-bridgebot:latest

heroku@9bda9cb34302:/workspace$ launcher bash

heroku@9bda9cb34302:/workspace$ which bridgebot
/cnb/process/bridgebot

heroku@9bda9cb34302:/workspace$ cat /layers/config/metadata.toml                    
...
[[processes]]
  type = "bridgebot"
  command = "bridgebot"
  args = []
  direct = true
  buildpack-id = "heroku/go"
...

And that gets it confused, as we are adding the /cnb/process path in the $PATH to support and ends up calling itself.

Probably it should use the full path, instead of just the procname (https://github.com/heroku/buildpacks-go/blob/main/buildpacks/go/src/proc.rs#L41), might send a patch/open a bug (though probably not today, /me on sick leave).

dcaro opened https://gitlab.wikimedia.org/repos/cloud/toolforge/builds-builder/-/merge_requests/45

procfile: avoid recursive calls for golang bulidpack

This should fix it on our side until we get the upstream side done:
https://gitlab.wikimedia.org/repos/cloud/toolforge/builds-builder/-/merge_requests/45

It changes the behavior a bit for golang buildservice images though, as now any system binary will shadow any procfile entry (while usually is the other way around).

dcaro merged https://gitlab.wikimedia.org/repos/cloud/toolforge/builds-builder/-/merge_requests/45

procfile: avoid recursive calls for golang bulidpack

project_1317_bot_df3177307bed93c3f34e421e26c86e38 opened https://gitlab.wikimedia.org/repos/cloud/toolforge/toolforge-deploy/-/merge_requests/277

builds-builder: bump to 0.0.104-20240506093336-61a74e27

dcaro opened https://gitlab.wikimedia.org/repos/cloud/toolforge/builds-builder/-/merge_requests/46

fix_nested_procfile: when appending use the right separator

dcaro merged https://gitlab.wikimedia.org/repos/cloud/toolforge/builds-builder/-/merge_requests/46

fix_nested_procfile: when appending use the right separator

dcaro merged https://gitlab.wikimedia.org/repos/cloud/toolforge/toolforge-deploy/-/merge_requests/277

builds-builder: bump to 0.0.104-20240506093336-61a74e27

@bd808 This should have been fixed, can you try now?

In T363417#9774388, @dcaro wrote:

@bd808 This should have been fixed, can you try now?

$ echo $PATH
/layers/heroku_go/go_target/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/cnb/process:/cnb/lifecycle
$ which bridgebot
/layers/heroku_go/go_target/bin/bridgebot
$ bridgebot --help
Usage of bridgebot:
  -conf string
        config file (default "etc/bridgebot.toml")
$ /cnb/process/bridgebot --help
Usage of bridgebot:
  -conf string
        config file (default "etc/bridgebot.toml")
$ /cnb/lifecycle/launcher bridgebot --help
Usage of bridgebot:
  -conf string
        config file (default "etc/bridgebot.toml")

Seems better, yes. Thanks for the quick hackfix.

Flagging as upstream to check in on it eventually