forgejo/runner

Watch

Fork 110

bug: runner is not respecting PATH in `envfile` for looking up `git` #1177

New issue

Closed

opened 2025-11-22 06:03:01 +00:00 by alexrp · 4 comments

alexrp commented

2025-11-22 06:03:01 +00:00

Contributor

Can you reproduce the bug on the Forgejo test instance?

Description

ci@freebie:~ $ which git
/usr/local/bin/git
ci@freebie:~ $ cat .env
PATH="/home/ci/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"

Yet:

freebie(version:v12.0.0) received task 2267481 of job x86_64-freebsd-debug, be triggered by event: push
workflow prepared
evaluating expression 'success()'
expression 'success()' evaluated to 'true'
  ☁️  git fetch 'https://data.forgejo.org/actions/checkout' # ref=v4
  git worktree create for ref=v4 (sha=34e114876b0b11c390a56381ad16ebd13914f8d5) to /home/ci/.cache/act/a5/2c9d9ce702a73250e89b57146dcd5ae5a3868abd7ff0891fc8b0cb92d012de
⚙️ [runner]: git worktree add error: : exec: "git": executable file not found in $PATH
skipping post step for 'Checkout'; step was not executed
🏁  Job failed
git worktree add error: : exec: "git": executable file not found in $PATH

Forgejo Version

Codeberg current

Runner Version

v12.0.0

How are you running Forgejo?

Codeberg

How are you running the Runner?

make build + rc.d

Logs

No response

Workflow file

No response

### Can you reproduce the bug on the Forgejo test instance? No ### Description ``` ci@freebie:~ $ which git /usr/local/bin/git ci@freebie:~ $ cat .env PATH="/home/ci/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin" ``` Yet: ``` freebie(version:v12.0.0) received task 2267481 of job x86_64-freebsd-debug, be triggered by event: push workflow prepared evaluating expression 'success()' expression 'success()' evaluated to 'true' ☁️ git fetch 'https://data.forgejo.org/actions/checkout' # ref=v4 git worktree create for ref=v4 (sha=34e114876b0b11c390a56381ad16ebd13914f8d5) to /home/ci/.cache/act/a5/2c9d9ce702a73250e89b57146dcd5ae5a3868abd7ff0891fc8b0cb92d012de ⚙️ [runner]: git worktree add error: : exec: "git": executable file not found in $PATH skipping post step for 'Checkout'; step was not executed 🏁 Job failed git worktree add error: : exec: "git": executable file not found in $PATH ``` ### Forgejo Version Codeberg current ### Runner Version v12.0.0 ### How are you running Forgejo? Codeberg ### How are you running the Runner? `make build` + rc.d ### Logs _No response_ ### Workflow file _No response_

alexrp added the

Kind/Bug

label

2025-11-22 06:03:01 +00:00

limiting-factor commented

2025-11-22 06:21:20 +00:00

Member

This is the documented breaking change of v12 https://code.forgejo.org/forgejo/runner/releases/tag/v12.0.0

You may want to wait for v12.0.1 before upgrading due to this regression.

This is the documented breaking change of v12 https://code.forgejo.org/forgejo/runner/releases/tag/v12.0.0 You may want to wait for v12.0.1 before upgrading due to [this regression](https://code.forgejo.org/forgejo/runner/pulls/1175).

alexrp commented

2025-11-22 06:25:07 +00:00

Author

Contributor

I'm aware of the breaking change, but I would still expect the runner to pick up PATH from the .env file (if any) in order to find executables that it depends on. It does so for node, for example, and we rely on that on most of our machines.

I'm aware of the breaking change, but I would still expect the runner to pick up `PATH` from the `.env` file (if any) in order to find executables that it depends on. It does so for `node`, for example, and we rely on that on most of our machines.

👍 1

mfenniak commented

2025-11-22 14:39:31 +00:00

Owner

I'm not sure about this; all the documentation related to the envfile support describes it as being used "in the containers", or "extra environment variables to run jobs from a file." This requirement for git is not at all related to the containers or jobs being executed. I recognize that there's some overlap here as you're using the host-based executor, and that environment file is used for command execution in that environment -- but there, node is being executed because it is referenced by the job, and git is being executed as a system requirement for the runner.

This could be made to work by pulling some chunks out of code out of the host executor, and dropping it into lower-level libraries that can be referenced by the git module. Then both envs and env_file option would need to be passed over to the clone system, which would be awkwardly pulled out of container-level options where the clone is invoked, as the system-level config isn't accessible there. It seems ugly but possible.

But I'm not sure it's right... for instance, on my NixOS system git isn't in a standard location. If I was setting a container-level PATH, I'd be setting it to standard Linux FHS so that it worked with ubuntu:latest, for example... and then it wouldn't be able to find my host's git. 🤔

I'm not sure about this; all the documentation related to the envfile support describes it as being used "in the containers", or "extra environment variables to **run jobs** from a file." This requirement for git is not at all related to the containers or jobs being executed. I recognize that there's some overlap here as you're using the host-based executor, and that environment file is used for command execution in that environment -- but there, `node` is being executed because it is referenced by the job, and `git` is being executed as a system requirement for the runner. This could be made to work by pulling some chunks out of code out of the host executor, and dropping it into lower-level libraries that can be referenced by the git module. Then both `envs` and `env_file` option would need to be passed over to the clone system, which would be awkwardly pulled out of container-level options where the clone is invoked, as the system-level config isn't accessible there. It seems ugly but possible. But I'm not sure it's right... for instance, on my NixOS system `git` isn't in a standard location. If I was setting a container-level `PATH`, I'd be setting it to standard Linux FHS so that it worked with `ubuntu:latest`, for example... and then it wouldn't be able to find my host's `git`. 🤔

alexrp commented

2025-11-22 16:54:24 +00:00

Author

Contributor

I see; if the env file is indeed only intended for the executor, then this behavior makes sense. I hadn't thought too deeply about that aspect since the line is a bit blurry in our case of only using host executors. I guess we'll just set PATH in the rc.d service script.

alexrp closed this issue

2025-11-22 16:54:24 +00:00

No milestone

No assignees

3 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

forgejo/runner#1177

No description provided.

Rows
Columns

bug: runner is not respecting PATH in envfile for looking up git #1177

Can you reproduce the bug on the Forgejo test instance?

Description

Forgejo Version

Runner Version

How are you running Forgejo?

How are you running the Runner?

Logs

Workflow file

bug: runner is not respecting PATH in `envfile` for looking up `git` #1177