4 ms·

Maybe this is just me, but needing to define environment variables or secrets for testing seems like a massive problem in the test design. Does that mean the t

Maybe this is just me, but needing to define environment variables or secrets for testing seems like a massive problem in the test design. Does that mean the tests are dependent on the use of an external service, and that service can't be run locally? The only part of a CI pipeline I can imagine requiring secrets would be a release/publish step. However, those would only occur after the tests run successfully, so nothing up until that point would require secrets.

Tainnor 3y ago
Just to give some examples: - your code is using private dependencies, so you can't build the code without authentication - you have some integration tests that use test containers using private docker images, so you need to do a "docker login" before running tests Locally, that would work because you're locally authenticated (and likely have all dependencies already installed etc.)
- MereInterest 3y ago
  Ah, I think I see. There is a dependency in the code that requires copying some external resource in order to build/run locally. The developer's local environment may have a different version of that resource than the CI, so a bug ends up not being reproducible. The developer may not run the CI directly, because the developer's access tokens should be separate from the CI's access tokens. I was picturing a case where the CI was allowed privileged access to a resource to which developers were not allowed access at all.
  - Tainnor 3y ago
    > I was picturing a case where the CI was allowed privileged access to a resource to which developers were not allowed access at all. That's also possible. Imagine a pipeline which carries out a deployment in an environment where normal devs are not allowed direct access to production machines / cluster (might happen in larger companies).

4 ms·

Maybe this is just me, but needing to define environment variables or secrets for testing seems like a massive problem in the test design. Does that mean the t

by MereInterest 3y ago

Tainnor 3y ago
Just to give some examples: - your code is using private dependencies, so you can't build the code without authentication - you have some integration tests that use test containers using private docker images, so you need to do a "docker login" before running tests Locally, that would work because you're locally authenticated (and likely have all dependencies already installed etc.)
- MereInterest 3y ago
  Ah, I think I see. There is a dependency in the code that requires copying some external resource in order to build/run locally. The developer's local environment may have a different version of that resource than the CI, so a bug ends up not being reproducible. The developer may not run the CI directly, because the developer's access tokens should be separate from the CI's access tokens. I was picturing a case where the CI was allowed privileged access to a resource to which developers were not allowed access at all.
  - Tainnor 3y ago
    > I was picturing a case where the CI was allowed privileged access to a resource to which developers were not allowed access at all. That's also possible. Imagine a pipeline which carries out a deployment in an environment where normal devs are not allowed direct access to production machines / cluster (might happen in larger companies).