Pipeline can't be run with env file having .yml suffix
See original GitHub issueDescription
Pipeline can’t be run with env.yml
file. It seems it won’t get read at all since variables stated in the env.yml
are unknown to the pipeline run. Renaming file to env.yaml
solved the issue for me.
Replication
Files for replication of minimal example are attached here.
Task
It would be nice to not be dependent on the suffix. Adjust the code, so it treats .yaml
and .yml
suffixes of env
file equally.
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
Make environment variables set in before_script available for ...
My pipeline consists of tests that check that the environment variables are correctly set after running the shell script to set/export them, and ......
Read more >Define variables - Azure Pipelines | Microsoft Learn
Don't set secret variables in your YAML file. Operating systems often log commands for the processes that they run, and you wouldn't want...
Read more >How do I use an env file with GitHub Actions? - Stack Overflow
A quick solution here could be having a step to manually create the .env file before you need it. - name: 'Create env...
Read more >Solved: Pipeline fails with No such file or directory
If your bitbucket-pipeline.yml was exactly as you shared, the problem is that the pipe is looking for files at "/" (root of the...
Read more >Keyword reference for the .gitlab-ci.yml file (FREE)
This example has strict rules, and pipelines do not run in any other case. Alternatively, all of the rules can be when: never...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Why not just read it as a yaml? and being extension agnostic as long as it’s a yaml format.
**In the case of 2 of the same it’ll create ambiguity, we can tell the user to conform with the .yaml extension and force a single extension
no worries! feel free to come back whenever you have time!