Replies: 1 comment
-
|
Probably you have found it yourself by now, just for the people like me who face the same issue now, you should point the env file path to /dev/null for your workflow envs to actually work locally. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hey everyone!
I've been using
actto debug Actions locally and encountered a behavior that I'd like to discuss. My use case involves running a test workflow with a Postgres service, where the DB credentials are set as environment variables. In my local setup, these credentials are defined in a.envfile for docker-compose, they are specific for my Docker environment, and some dummy credentials are set in the.github/workflows/ci.ymlfile. Here's a snippet of theci.yml:While using
act -j tests, I noticed that the.envfile, which is gitignored, was unexpectedly influencing the environment variables in the container. This behavior is due toact's default handling of.envfiles:$ act --help <...> --env-file string environment file to read and use as env in the containers (default ".env")I'm curious about the rationale behind this default behavior. In my view, when using
actto simulate GitHub Actions locally, the expectation is that only the environment variables defined in the workflow YAML should be considered, unless explicitly overridden. The automatic inclusion of the.envfile, especially when it's commonly used for other development purposes, seems counterintuitive and potentially problematic.Consider this simple example for clarity:
.github/workflows/test.yml:.envcontents:Running
act -j testoutputsbarinstead of the expectedfoo.Given these observations, wouldn't it be more intuitive for
actto not use--env-fileby default or at least provide a clearer warning about this behavior?Beta Was this translation helpful? Give feedback.
All reactions