environment-to-ini does not work with INSTALL_LOCK #11246

New Issue

GiteaMirror · 2025-11-02T09:32:05-06:00

GiteaMirror commented

2025-11-02 09:32:05 -06:00

Originally created by @codello on GitHub (Jul 17, 2023).

Originally assigned to: @wxiaoguang on GitHub.

Description

Running environment-to-ini on a partial config file will not apply environment variables if the source file has INSTALL_LOCK = true. This is a change in behavior to previous versions of the Gitea docker image.

Reproducable Example

Given this example.ini

[security]
INSTALL_LOCK = true

run

export GITEA__database__DB_TYPE=postgres
environment-to-ini --config=example.init --out=out.ini
cat out.ini

Actual result:

[security]
INSTALL_LOCK = true

Expected result:

[security]
INSTALL_LOCK = true

[database]
DB_TYPE = postgres

Workaround

For Gitea v1.20.0 a possible workaround is to set GITEA__security__INSTALL_LOCK=true in the environment and have INSTALL_LOCK = false (or absent) in the source config. This results in the desired configuration.

Additional Details

As mentioned above this behavior is new in Gitea v1.20.0. Previous versions produced the expected result. I suspect that #25330 caused the change of behavior but haven't checked thoroughly.

The issue seems to be caused by setting.InitWorkPathAndCfgProvider(…) which is called by environment-to-ini to load the existing config file. That function then clears the environment, causing environment-to-ini not to perform any changes.
81a8120bc3/modules/setting/path.go (L174-L176)

This bug report is specific to environment-to-ini so the rest of this form only partially applies.

Gitea Version

v1.20.0

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

no logs produced / does not apply

Screenshots

No response

Git Version

2.40.1

Operating System

Alpine Linux v3.18 (official docker image) on Fedora 38 (host)

How are you running Gitea?

This bug is specific to environment-from-ini and occurs before Gitea actually starts.

I run Gitea via the official docker image gitea/gitea:1.20.0-rootless. Starting this image with an interactive shell allows you to reproduce the issue.

Alternatively run

docker run --rm -i gitea/gitea:1.20.0-rootless bash <<-EOF
mkdir /tmp/test
cd /tmp/test
export GITEA__database__DB_TYPE=postgres
echo "[security]
INSTALL_LOCK = true
" > example.ini
environment-to-ini --config=example.ini --out=out.ini
cat out.ini
EOF

Database

PostgreSQL

Originally created by @codello on GitHub (Jul 17, 2023). Originally assigned to: @wxiaoguang on GitHub. ### Description Running `environment-to-ini` on a partial config file will not apply environment variables if the source file has `INSTALL_LOCK = true`. This is a change in behavior to previous versions of the Gitea docker image. ## Reproducable Example Given this `example.ini` ```ini [security] INSTALL_LOCK = true ``` run ```shell export GITEA__database__DB_TYPE=postgres environment-to-ini --config=example.init --out=out.ini cat out.ini ``` Actual result: ```ini [security] INSTALL_LOCK = true ``` Expected result: ```ini [security] INSTALL_LOCK = true [database] DB_TYPE = postgres ``` ## Workaround For Gitea v1.20.0 a possible workaround is to set `GITEA__security__INSTALL_LOCK=true` in the environment and have `INSTALL_LOCK = false` (or absent) in the source config. This results in the desired configuration. ## Additional Details As mentioned above this behavior is new in Gitea v1.20.0. Previous versions produced the expected result. I suspect that #25330 caused the change of behavior but haven't checked thoroughly. The issue seems to be caused by `setting.InitWorkPathAndCfgProvider(…)` which is called by `environment-to-ini` to load the existing config file. That function then clears the environment, causing `environment-to-ini` not to perform any changes. https://github.com/go-gitea/gitea/blob/81a8120bc3e023b3729473adf87f399ec70e8cde/modules/setting/path.go#L174-L176 --- This bug report is specific to `environment-to-ini` so the rest of this form only partially applies. ### Gitea Version v1.20.0 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist no logs produced / does not apply ### Screenshots _No response_ ### Git Version 2.40.1 ### Operating System Alpine Linux v3.18 (official docker image) on Fedora 38 (host) ### How are you running Gitea? This bug is specific to `environment-from-ini` and occurs before Gitea actually starts. I run Gitea via the official docker image `gitea/gitea:1.20.0-rootless`. Starting this image with an interactive shell allows you to reproduce the issue. Alternatively run ```shell docker run --rm -i gitea/gitea:1.20.0-rootless bash <<-EOF mkdir /tmp/test cd /tmp/test export GITEA__database__DB_TYPE=postgres echo "[security] INSTALL_LOCK = true " > example.ini environment-to-ini --config=example.ini --out=out.ini cat out.ini EOF ``` ### Database PostgreSQL

GiteaMirror added the type/bug label 2025-11-02 09:32:06 -06:00

GiteaMirror closed this issue

2025-11-02 09:32:06 -06:00

GiteaMirror commented

2025-11-02 09:32:06 -06:00

@wxiaoguang commented on GitHub (Jul 17, 2023):

Thank you for the detailed report. Will fix it soon.

@wxiaoguang commented on GitHub (Jul 17, 2023): Thank you for the detailed report. Will fix it soon.

GiteaMirror commented

2025-11-02 09:32:07 -06:00

@wxiaoguang commented on GitHub (Jul 17, 2023):

(Regression of Make "install page" respect environment config #25648)

-> Make environment-to-ini work with INSTALL_LOCK=true #25926

@wxiaoguang commented on GitHub (Jul 17, 2023): (Regression of Make "install page" respect environment config #25648) -> Make environment-to-ini work with INSTALL_LOCK=true #25926

GiteaMirror commented

2025-11-02 09:32:07 -06:00

@wxiaoguang commented on GitHub (Jul 18, 2023):

Could you try the nightly build (tag: 1.20-nightly and 1.20-nightly-rootless)? I think it should have been fixed.

@wxiaoguang commented on GitHub (Jul 18, 2023): Could you try the nightly build (tag: `1.20-nightly` and `1.20-nightly-rootless`)? I think it should have been fixed.

GiteaMirror commented

2025-11-02 09:32:07 -06:00

@codello commented on GitHub (Jul 19, 2023):

Thanks a lot. I can confirm that the issue is fixed in both 1.20-nightly and 1.20-nightly-rootless.

@codello commented on GitHub (Jul 19, 2023): Thanks a lot. I can confirm that the issue is fixed in both `1.20-nightly` and `1.20-nightly-rootless`.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#11246