-
Notifications
You must be signed in to change notification settings - Fork 891
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Unrecognized named-value: 'env'. Located at position 1 within expression" when used in reusable workflow jobs #2372
Comments
I'm having the same issue |
I have the same issue, there is workaround to use |
Having the same issue . When it's going to fix? |
Hi GHA folks: Any update on providing this capability? Some of us are using workarounds, including the one suggested by @nicole0707. But, having this feature will make the intent very clear and clean. |
hello! if i can help u. or something need to do.say step b step |
workaround is to use as a secret in the main workflows and then you'll be able to parse it to env in the reusable workflow like
|
I'm having the same issue. Have we got any update? |
In my case, git is considering subscription id as a secret. I am trying to print NSG/ASG id and git is omitting the output. |
Trying to use this approach to workaround #520 and bummer... |
- use public qodana linter for PRs - do not collect and analyze coverage Coverage analysis suppressed in the _coverage.yml instead of main workflow because of the bug on actions side, see actions/runner#2372
It is also unavailable in called workflow. I tried to move check into there and got:
Called workflow is:
|
- use public qodana linter for PRs - do not collect and analyze coverage Coverage analysis suppressed in the _coverage.yml instead of main workflow because of the bug on actions side, see actions/runner#2372
- use public qodana linter for PRs - do not collect and analyze coverage Coverage analysis suppressed in the _coverage.yml instead of main workflow because of the bug on actions side, see actions/runner#2372
I'm having the same issue 😐 |
+1 |
+1. Get this fixed github, cmon. |
The env context is not available from jobs.<job_id>.with.<with_id>. See https://docs.github.com/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#context-availability |
@whsalazar the question is what the reason behind this? And if there is no real reason, would be nice to have it. |
I guess I wasted 30 mins of my life and ended up here like the rest of us |
You can't use the env context outside steps, as described in the docs: You can use the env context in the value of any key in a step except for the id and uses keys. Feel free to submit feedback and feature request at https://github.com/orgs/community/discussions/categories/actions?discussions_q=is%3Aopen+env+jobs+category%3AActions |
I have the same issue, hope github action can pass the env variable in the furture |
Nasty workaround: https://stackoverflow.com/a/74217028/834280 |
Same problem here. I have several reusable workflows that should receive the same |
The solution is to pass the environment variables as the output of a job:
|
Hey this got me really close - at least now i can reference names of env vars I need in
|
@ffineis To pass secrets use |
@miguelangelgil yes thanks |
You can use |
2023 and still have the same issue |
+1 |
5 similar comments
+1 |
+1 |
+1 |
+1 |
+1 |
Why this issue is closed?!!! We are still seeing the error on our shared workflows that the |
+1 |
+1 |
…reason (see actions/runner#2372).. 7cbb7fdbbd1ec0f94cdbb2b540241b49606a8bc7
+1 |
4 similar comments
+1 |
+1 |
+1 |
+1 |
### Why: Workflow is invalid in its current state and never runs ### What's being changed (if available, include any code snippets, screenshots, or gifs): - Use [outputs hack](actions/runner#2372) to load environment variables into the job-level conditional if --------- Co-authored-by: Dawson Booth <dawson@dawsonbooth.com>
Workflow is invalid in its current state and never runs screenshots, or gifs): - Use [outputs hack](actions/runner#2372) to load environment variables into the job-level conditional if Co-Authored-By: Dawson Booth <dawson@dawsonbooth.com>
This is only relevant for repository level variables. |
+1 We moved from GitLab years ago, and are still missing what we thought would be key/obvious features |
+1 |
Just checked the code for the runner and current impression is that this can not be fixed on runner side as the conditions which jobs get executed is taken server side. A runner simply executes all Jobs it gets, I could not find any conditions checking (found them for steps where this is working fine) Sadly server part is not open source so hard to support with fixing this |
I bumped into this; and resolved it by using It's not a long-term solution since it leads to a deprecation warning, nor is it appropriate for sensitive variables: " |
We were trying to use a repeated container image name. For anyone still searching, this part of the docs (from this comment) explained it for us. The It looks like YAML anchors are not supported and there might be a route forwards with repository variables in the |
Describe the bug
Usage of env in workflow that uses reusable workflow generates "Unrecognized named-value: 'env'. Located at position 1 within expression"
To Reproduce
Use the following yml:
Expected behavior
env.SOMETHING is usable and can be passed into reusable workflow
Actual behavior
The workflow is not valid. .github/workflows/create-branch.yml (Line: #, Col: ##): Unrecognized named-value: 'env'. Located at position 1 within expression: env.SOMETHING
Runner Version and Platform
Version of your runner?
OS of the machine running the runner?
ubuntu-latest
What's not working?
The text was updated successfully, but these errors were encountered: