Checking if variable is null in Gitlab pipeline - gitlab

Question

How to check a null variable in Gitlab pipeline when it's declared with a content of another null variable? Like the variable VAR_NULL below when NO_VAR is null:
variables:
VAR_EMPTY: ""
VAR_NULL: "${NO_VAR}"
Check the pipeline result out where only VAR_EMPTY == "" and NO_VAR == null evaluate to true all others are false.
Pipeline result (a screenshot for convenience, the full result: https://gitlab.com/labaz/test-gitlab-pipeline-null-var/-/pipelines/493036820):
Full pipeline script (https://gitlab.com/labaz/test-gitlab-pipeline-null-var/-/blob/main/.gitlab-ci.yml):
variables:
VAR_EMPTY: ""
VAR_NULL: "${NO_VAR}"
jobTest-Var_Empty-IsNull: # This job runs in the build stage, which runs first.
rules:
- if: '$VAR_EMPTY == null'
script:
- 'echo "VAR_EMPTY IS null"'
jobTest-Var_Empty-IsEmpty: # This job runs in the build stage, which runs first.
rules:
- if: '$VAR_EMPTY == ""'
script:
- 'echo "VAR_EMPTY IS \"\""'
jobTest-Var_Null-IsNull: # This job runs in the build stage, which runs first.
rules:
- if: '$VAR_NULL == null'
script:
- 'echo "VAR_NULL IS null"'
jobTest-Var_Null-IsEmpty: # This job runs in the build stage, which runs first.
rules:
- if: '$VAR_NULL == ""'
script:
- 'echo "VAR_NULL IS Empty"'
jobTest-No_Var-IsNull: # This job runs in the build stage, which runs first.
rules:
- if: '$NO_VAR == null'
script:
- 'echo "NO_VAR IS null"'
jobTest_No_Var-IsEmpty: # This job runs in the build stage, which runs first.
rules:
- if: '$NO_VAR == ""'
script:
- 'echo "NO_VAR IS Empty"'

Answer 1

The problem you're encountering is that VAR_NULL: "${NO_VAR}" is not a null variable. It's actually the same thing as VAR_EMPTY: "" -- you are declaring the variable (therefore it is not null) with an empty value.
The only way to test if the variable was created with another empty variable is to test the original variable itself. That is, test NO_VAR, not VAR_NULL.
An alternative strategy would be to use rules:variables: in order to conditionally declare VAR_NULL
workflow:
rules:
- if: '$NO_VAR' # or '$NO_VAR != null' depending on what you want
variables:
VAR_NULL: "$NO_VAR"
- when: always
jobTest-Var_Null-IsNull:
rules:
- if: '$VAR_NULL == null'
script:
- echo "VAR_NULL is null"

Answer 2

As soon as any "if" is matched the job runs.
there's no overriding it with a later "never"
also 'if when never' - who thought that was a good idea?
Anyhow to make the if less matchy ... you can use parentheses.
rules:
- if: ($CI_COMMIT_BRANCH && $SOME_VAR == null)
However this doesn't work:
- if: ('$CI_COMMIT_BRANCH == develop' && $SOME_VAR == null)
not sure why considering this is valid...
- if: '$CI_COMMIT_BRANCH == develop'
essentially I want to skip some jobs when 'some_var' is set (which happens when I run a manual pipeline)
So putting it all together ...
And before your eyes glaze over "workflow" and its "rules" are a separate beast from "job_name:" "rules:"
ostensibly workflow needs "always or never" and the rules can control when jobs run.. but only if you put a "never" .. unless i'm missing something... )
workflow:
rules:
- if: '$SOMEVAR == null'
variables:
BLOCK_JOB: "False"
- when: always
#then in my job we can do something like:
rules:
- if: ($CI_COMMIT_BRANCH == "develop" && $BLOCK_JOB)
yes all of that because this doesn't work
- if: ('$CI_COMMIT_BRANCH == develop' && $SOME_VAR == null)
so now I can have a job that runs on develop unless its run manually (which is when I set SOMEVAR)
and then its skipped.
Workflow also seems to just randomly refuse to do somethings...
for example this Doesn't work ( trying to set a var based on project name) never evals as true so CI_PATH_TYPE remains unset... but imo looking at it with my wetware... it should...
rules:
- if: $CI_PROJECT_NAME == "some-project-name"
variables:
CI_PATH_TYPE: project
But this does? because.. null is magic..?
rules:
- if: '$somevar == null'
variables:
BLOCK_JOB: "False"
also any time something is quoted in various ways in these examples gitlab ci made me do it exactly like that, any other variations and it shits the bed.
so once again the latest tool is just more black magic, hot take: gitlab-ci is bad.