Protected variable falls back to empty string (with dire consequences)

GitLab CI/CD
1

I’ve noticed this behavior and it’s had a pretty bad outcome for us, posting to see if this is intentional, or if I should file a bug report.

CI/CD variables are now protected by default. When trying to access these from an unprotected branch, this doesn’t produce an error, but rather the variable defaults to an empty string.

In our case we had the following variables:

S3_BUCKET (unprotected)
S3_PATH (protected, unintentionally, should've been set to unprotected)

In our .gitlab-ci.yml we had then following line:

- aws s3 sync build/ s3://$S3_BUCKET/$S3_PATH --delete --acl public-read

The pipeline was then run from an unprotected branch. As a consequence it did fill in the S3_BUCKET variable, but also the S3_PATH which became an empty string. So instead of deploying to the specified path, it deployed to the s3 bucket root, deleting everything in the bucket in the process!

Would be glad to hear your thoughts on this.

1 Like
2

That is a very rough one, I feel for you. I came across this thread because I’m having an issue with empty variable values that shouldn’t be. Only suggestion/take away I see from what you posted is if you’re doing something that is writing or deleting you should very much confirm your variable before proceeding with some kind of if [ $var != "" ] equivalent to ensure you’re not passing a blank variable.

3

Hit this today as well, I really want unprotected branchs to not have any environment variable set. My program sets env variables if they are not set but overrides the env variables in the program if they are set so in my case an empty string is used as the password which is not what I want in my MR pipelines.

To fix this I did this

  • $env:ENVIRONMENT_VAR=“” #Blank this out just for local dev

as a step in my script