the procfile may not support setting envvars like that. If that's true, I see two options:

• use the toolforge envvars, they work fine as you discovered
• wrap the call to your code in a shell script, then call the shell script from the procfile. The shell script can contain whatever logic to set env vars.

Our Rust tutorial suggests variable in Procfile should be working. I'm not sure why they are not working for you.

wrap the call to your code in a shell script

This is a sensible workaround if you want to have the variable stored in Git, as opposed to toolforge envvars that are separate from your codebase.

Some notes from a quick check:

The envvar is there when executing inside the container, and it's kept even after running the launcher wrapper:

(venv) tools.campwiz-bot@tools-bastion-13:~$ kubectl exec -ti campwiz-bot-54f749fc5f-jrvx2 bash
...
I have no name!@campwiz-bot-54f749fc5f-jrvx2:/workspace$ echo $GIN_MODE
release
...
I have no name!@campwiz-bot-54f749fc5f-jrvx2:/workspace$ launcher bash
...
I have no name!@campwiz-bot-54f749fc5f-jrvx2:/workspace$ echo $GIN_MODE
release

It is also in the environment of the golang process: update it was not the golang process, but the shell

I have no name!@campwiz-bot-54f749fc5f-jrvx2:/workspace$ strings /proc/34/environ 
...
GIN_MODE=release
...

I think I found something, the command that the webservice runs is actually set by the golang buildpack, not the procfile one it seems, might be an ordering issue, looking

dcaro@devforge:~$ docker inspect 192.168.5.15/tool-tf-test2/tool-tf-test2:latest | jq '.[].Config.Labels."io.buildpacks.build.metadata"' -r | jq '.processes'
[
  {
    "type": "campwiz-test",
    "command": "campwiz-test",
    "args": [],
    "direct": true,
    "buildpackID": "heroku/go"
  },
  {
    "type": "web",
    "command": "campwiz-test",
    "args": [],
    "direct": true,
    "buildpackID": "heroku/go"
  }
]

@Nokib_Sarkar I created https://github.com/nokibsarkar/campwiz-test/pull/1 , that should fix the issue :)

Tested it on my local dev environment (lima-kilo):

...
[step-detect] 2025-04-23T09:17:02.300407364Z 2 of 4 buildpacks participating
[step-detect] 2025-04-23T09:17:02.300464477Z heroku/go       0.1.13                                                                            
[step-detect] 2025-04-23T09:17:02.300468953Z heroku/procfile 2.0.2  
...

There are two issues:

• The name of the procfile should be Procfile, it's case sensitive :/
• There seems to be a weird behavior of the procfile buildpack, where if you only declare the web entry it will not override the golang buildpack (looking), adding a silly new entry works and overwrites the web one too as a workaround

There seems to be a weird behavior of the procfile buildpack, where if you only declare the web entry it will not override the golang buildpack (looking), adding a silly new entry works and overwrites the web one too as a workaround

This is fixed on the next version of the buildpacks (coming soon!):

dcaro@devforge:/home/dcaro/Work/wikimedia/lima-kilo$ docker inspect 192.168.5.15/tool-tf-test2/tool-tf-test2:latest | jq '.[].Config.Labels."io.buildpacks.build.metadata"' -r | jq '.processes'
[
  {
    "type": "web",
    "command": "bash",
    "args": [
      "-c",
      "sh -c 'GIN_MODE=release ./campwiz-test'"
    ],
    "direct": true,
    "buildpackID": "heroku/procfile"
  }
]

@Nokib_Sarkar Hi! can you try using toolforge build start --use-latest-versions <http://url>? That should pull now the latest buildpacks, including the procfile fix, and golang with support for newer versions

Tested also that it works now with golang 1.24:

local.tf-test@toolslocal:~$ toolforge build start https://github.com/david-caro/campwiz-test --use-latest-versions
...
[step-build] 2025-05-14T09:24:14.746698709Z [Installing Go distribution]
[step-build] 2025-05-14T09:24:14.746816044Z Installing go1.24.1 (linux-amd64) from https://go.dev/dl/go1.24.1.linux-amd64.tar.gz
[step-build] 2025-05-14T09:24:18.960023212Z 
[step-build] 2025-05-14T09:24:18.960516726Z [Building Go binaries]
[step-build] 2025-05-14T09:24:18.960528317Z Creating new Go modules cache
...

So, The Issue is fixed apparently.

In T390845#10822308, @Nokib_Sarkar wrote:

So, The Issue is fixed apparently.

I'll close the task then :), feel free to create a new one if you find any more issues with the new builder.