When I didn't set an API key in the environment variables, the error looked like this:
I encountered this error when there was a linting issue in the .yaml file. I identified it as a linting error after checking the deployment status in Reunite. I'm not sure about the expected behavior, but if a "contractor" doesn't have access to Reunite, they should be able to see this information in the GitHub Actions console.
When I pushed "bad changes" to the main branch via PR, I received a "Preview deploy fail" message, but the overall action still showed "success" at the end. This seems confusing as the failure didn't affect the final status.
When I fixed indentation and pushed directly to the main branch, GitHub Actions didn't detect the changes and therefore didn't run the deployment workflow
Is the CI/CD viable for this purpose?
Yes, CI/CD works well here because it lets us automatically check and publish the contractor’s changes without giving them access to our main repository.
How would credentials be transmitted to the contractor?
There are two options: either we create and own the repository and store the API key as a GitHub secret there, or the contractor uses their own repository and we securely provide the API key so they can configure it as a secret themselves.
Is that secure?
The first option is the most secure because the contractor never sees the API key, while the second option is less secure since the key must be shared and trusted to be handled correctly.
Do you see any potential pitfalls?
Possible issues include weak validation and error feedback, missing branch protection, or using the second option where credentials are shared and harder to control.
