build_command environment variables not working after upgrade from 9.6.0 to 9.7.0 #922
Comments
tkcontiant
changed the title
|
@tkcontiant, thank you for the bug report. The change in |
|
Hello, notying bad has happend I actually whanted to upgrade to 9.7.1 and
the variables are really cool.. NEXT_VERSION var is really needed.. and
awsome feature..
In my workflow I amd building docker images, so some lever of accessing nev
vars is required for docker in docker to work and application_name..
If you say I can activate env = true this will solve the entire problem.
I would search today maybe there si a parameter wich I missed.
Just to let you onow the navrs are working great.. Accrdoing to the release
9.7.x
Maybe simple map with wich vars to pass additionally from env would be
another idea? So you can keep the new vars and if someone like me needs
also to access os env would be fine and easy to transition.
…On Fri, May 10, 2024, 3:35 AM codejedi365 ***@***.***> wrote:
@tkcontiant <https://github.com/tkcontiant>, thank you for the bug
report. The change in v9.7.0
<https://github.com/python-semantic-release/python-semantic-release/releases/tag/v9.7.0>
adjusted the environment that is passed to the build command subprocess.
Due to your report, I now know that when the subprocess parameter env was
set to None (implicitly) that defaulted to pass all environment variables
to the build process. I did not expect that as I moved to explicitly define
the environment so I could insert some dynamic variables. Will need to
reconsider the implementation. I apologize for the inconvenience.
—
Reply to this email directly, view it on GitHub
<#922 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BFUIJ3ORGBBWB4JWMILMNNDZBQW7ZAVCNFSM6AAAAABHPKW2FWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBTG42TGMJVGY>
.
You are receiving this because you were mentioned.Message ID:
<python-semantic-release/python-semantic-release/issues/922/2103753156@
github.com>
|
|
Thank you for the feedback! Yes, I'm leaning towards a configuration option like The reason I am steering away from just a blind copy of all env variables of the parent process is because PSR is being entrusted with users authentication tokens and I would not want to pass those on to sublibraries that should not have them. If there are other variables that PSR should inject into the environment from internal processing please let me know |
|
True, I guess simple list with envs to propagte would be great addition..
…On Fri, May 10, 2024, 1:11 PM codejedi365 ***@***.***> wrote:
Thank you for the feedback! Yes, I'm leaning towards a configuration
option like build_command_env which is a list of strings. They either
need to be in the format NAME=value to hardcode values to be passed or
just NAME to copy the var from the parent process env.
The reason I am steering away from just a blind copy of all env variables
of the parent process is because PSR is being entrusted with users
authentication tokens and I would not want to pass those on to sublibraries
that should not have them.
—
Reply to this email directly, view it on GitHub
<#922 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BFUIJ3KUTTAMOYIPITXBXM3ZBS2QBAVCNFSM6AAAAABHPKW2FWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBUGUYDAMZSHA>
.
You are receiving this because you were mentioned.Message ID:
<python-semantic-release/python-semantic-release/issues/922/2104500328@
github.com>
|
|
Also, keep in mind that CI or local build environments should be considered safe. Normally people are having way worse stuff hardcoded in their build environments not just auth tokens and stuff. In my case I am building everything in K8s so, I consider the build environment as ephemeral... temp. |
🎉 This issue has been resolved in version 9.7.2 🎉The release is available on: |
|
@tkcontiant, Thank you for your input and issue report. The following configuration should provide the environment that you seek. Let me know if it doesn't work for you. diff a/pyproject.toml b/pyproject.toml
[tool.semantic_release]
build_command = "buildah bud -t ${APPLICATION_NAME}:${CI_JOB_ID} ."
+ build_command_env = [
+ "APPLICATION_NAME",
+ "CI_JOB_ID",
+ ]ref: https://python-semantic-release.readthedocs.io/en/latest/configuration.html#build-command-env |
|
Hello,
Thank you for your support and that you are providing this product to the
comunity.
I will test today and let you know..
…On Mon, May 13, 2024, 4:28 AM codejedi365 ***@***.***> wrote:
@tkcontiant <https://github.com/tkcontiant>, Thank you for your input and
issue report. The following configuration should provide the environment
that you seek. Let me know if it doesn't work for you.
diff a/pyproject.toml b/pyproject.toml
[tool.semantic_release]
build_command = "buildah bud -t ${APPLICATION_NAME}:${CI_JOB_ID} ."+ build_command_env = [+ "APPLICATION_NAME",+ "CI_JOB_ID",+ ]
ref:
https://python-semantic-release.readthedocs.io/en/latest/configuration.html#build-command-env
—
Reply to this email directly, view it on GitHub
<#922 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BFUIJ3JI6DYJGSVAUNAXZTTZCAXM5AVCNFSM6AAAAABHPKW2FWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBWGU3DMOJQGE>
.
You are receiving this because you were mentioned.Message ID:
<python-semantic-release/python-semantic-release/issues/922/2106566901@
github.com>
|
The problem
I am using environment variables in the build command and this use to work.
build_command = "buildah bud -t ${APPLICATION_NAME}:${CI_JOB_ID} ." semantic-release version --patchI found that semantic-release is not able to access environment variables at all.
I tried with simple echo and I got empty strings.
Expected behavior
Execute the build and respect my environment variables
Environment
alpine:3.19.1
semantic-release, version 9.7.1
Please also indicate which Python build tool(s) you are using (e.g.
pip,build,poetry, etc.), including the version number too.Configuration
Please add your
semantic-releaseconfiguration, and if applicable also provideyour
build-systemconfiguration frompyproject.toml.Logs
Please provide debug logs for the command you are using with the
-vvflag, e.g.If using GitHub actions, ensure the
root_optionscontains the-vvflagfor verbosity, and attach your workflow definition.
Additional context
Add any other information that could be useful, such as a link to your project
(if public), links to a failing GitHub Action, or an example commit.
The text was updated successfully, but these errors were encountered: