Allows for passing secrets to the docker-compose-test workflow via a .env file

[vishnuravi]

Allows for passing secrets to the docker-compose-test workflow via a .env file

♻️ Current situation & Problem

We may need to pass secrets as environment variables when testing with docker, but there is currently no method to do this.

⚙️ Release Notes

Allows setting an ENV_FILE secret which will be written into a .env file before running the docker-compose command.

Code of Conduct & Contributing Guidelines

By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines:

• I agree to follow the Code of Conduct and Contributing Guidelines.

[Supereg]

Looking good 🚀

[vishnuravi]

Looking good 🚀

Thank you for the review @Supereg!

[PSchmiedmayer]

Thank you @vishnuravi for the PR and the review @Supereg!

Would just want to check in if we can verify that the functionality works within the Web Dashboard Template repo as I see the build failing there: https://github.com/StanfordSpezi/SpeziTemplateWebDashboard/actions/runs/6949756823/job/18908599448?pr=4
Is that due to an other reason or this PR?

I made the experience that storing files in secrets as a non-base64 representation results in undefined behaviour.

Therefore we encode all files in the other GitHub Actions as base64 representations in the secrets and decode it in the GitHub action. If the build is failing due to other reasons feel free to discard this comment; just a first thought and help while I am out of the office.

I would also suggest to make the step optional if there is no value in the secrets passed in so we don't create empty env files or override env files if there is nothing passed to the reusable GitHub action.

[vishnuravi]

Hi @PSchmiedmayer, thanks for the feedback. The issue was with the Dockerfile itself, not the secret. It seems that GitHub is preserving the formatting and line breaks of the .env file when placed in the secret. We can use base64, although it does add an extra step. Your suggestion about making the step optional is a good one and we can add this to the next release of this action.

[PSchmiedmayer]

Sounds good, thanks for the context. If there is no need for a base64 representation then we should be fine without it and can skip the encoding and decoding.

Sounds good 🚀