Why does .env contents override env section in workflows by default?

[ddoroshev]

Hey everyone!

I've been using act to 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 .env file for docker-compose, they are specific for my Docker environment, and some dummy credentials are set in the .github/workflows/ci.yml file. Here's a snippet of the ci.yml:

jobs:
  tests:
    runs-on: ubuntu-latest
    env:
      <...>
      DB_HOST: localhost
    <...>

While using act -j tests, I noticed that the .env file, which is gitignored, was unexpectedly influencing the environment variables in the container. This behavior is due to act's default handling of .env files:

$ 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 act to 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 .env file, 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:

  name: Test
  env:
    SAMPLE_VAR: 'foo'
  jobs:
    test:
      runs-on: ubuntu-latest
      steps:
        - name: Show the var
          run: echo $SAMPLE_VAR

• .env contents:

  SAMPLE_VAR=bar

• Running act -j test outputs bar instead of the expected foo.

Given these observations, wouldn't it be more intuitive for act to not use --env-file by default or at least provide a clearer warning about this behavior?