Why does running pipelines on commits fails with "bash: [: ==: unary operator expected"

[serhatakbak]

Is it a bug or some kind of rule that I don't know but when I manually run a pipeline on a past commit for a second time (on the same commit that initiated the pipeline, and ended up with a successful build and deployment afterwards), build step fails with the message "bash: [: ==: unary operator expected", but as if it wasn't error to fail the pipeline. Likewise, the same error happens if I try to run the pipeline manually on commits that've not started the pipeline because I've made another commits later on. Why is that?

[Theodora Boudale · Accepted solution]

Hi @serhatakbak,

Is this message displayed in the output of a certain command during your build?

If so, what is the command that gives this output and what is the full output of this command? Are you running the build step with this command in our own infrastructure, or are you using one of our Runners?

If you don't feel comfortable sharing this info here, you can create a ticket with the support team. If we have an open support ticket, the engineer working on it will be able to access your build logs and troubleshooting should be faster.

You can create a ticket via https://support.atlassian.com/contact/#/, in "What can we help you with?" select "Technical issues and bugs" and then Bitbucket Cloud as product. Please make sure to provide the URL of a build with this issue in the ticket description (the support ticket will be visible only to you and Atlassian staff).

Please feel free to let me know if you have any questions.

Kind regards,
Theodora

[serhatakbak]

Hello Theodora,

I think there's no need to hide any information; so, let's answer your questions; firstly, this error message is not special to build steps only but all of them; the weird thing is that each step follows the next one as if they were successful but, of course, with the same message, "bash: [: ==: unary operator expected."

Is this message displayed in the output of a certain command during your build?

No, this message is displayed regardless of what command we run in any step.

 [...] this command in our own infrastructure, or are you using one of our Runners?

No, we use Bitbucket servers; there're some steps that triggers something else in remote machines, but those also give the same message without taking any action set in pipelines; so, I believe this relates to Bitbucket anyway. Actually, there's no need to open a ticket or anything; just go to commits from the left bar and click run pipeline button as in the image below, which'll give the same error.

But I need to make an UPDATE on my initial query: running the pipelines on a commit that's successfully initiated and completed pipelines is still OK (I probably misinterpreted my test results); however, running the pipeline on a commit that's NOT initiated a pipeline (because there's been other commits after it, and then final push to initiate the pipeline), fails or gives this message and acts as if it was OK

[Theodora Boudale]

Hi @serhatakbak,

Thank you for the details.

I'm afraid that I am not able to reproduce this issue in a repository of mine (I tried running manually a build from the Commits page, for a commit that did not previously initiate a pipelines build). I don't see any other reports about this issue, and I don't have access to your repo so I cannot really see where this message shows and any additional logs.

If this message shows in the Pipelines build log, can you download the build log (there is an icon at the top right corner of the build log), and share its content here (after sanitizing any private/sensitive data) so I can take a look?

If the message doesn't show in the build log, can you provide a screenshot and/or a description of where exactly you see this message?

Kind regards,
Theodora

[serhatakbak]

Hi again,

May you please confirm that you've tried to initialize a pipeline on a commit after which another commits have been made? I rigidly, and maybe annoyingly, keep asking that because I can reproduce the error. Here's the error log you've asked:

To add, caching doesn't work as expected, either.

Cordially

+ umask 000

+ GIT_LFS_SKIP_SMUDGE=1 retry 6 git clone -n https://x-token-auth:$REPOSITORY_OAUTH_ACCESS_TOKEN@bitbucket.org/$BITBUCKET_REPO_FULL_NAME.git $BUILD_DIR
Cloning into '/opt/atlassian/pipelines/agent/build'...

+ git checkout 3e0f90bdc0479ac45cd09243e7965818f8394183
Note: switching to '3e0f90bdc0479ac45cd09243e7965818f8394183'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

git switch -c <new-branch-name>

Or undo this operation with:

git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 3e0f90b COnsole log test message is inserted

+ git config user.name bitbucket-pipelines

+ git config user.email commits-noreply@bitbucket.org

+ git config push.default current

+ git config http.${BITBUCKET_GIT_HTTP_ORIGIN}.proxy http://localhost:29418/

+ git remote set-url origin http://bitbucket.org/$BITBUCKET_REPO_FULL_NAME

+ git reflog expire --expire=all --all

+ echo ".bitbucket/pipelines/generated" >> .git/info/exclude

+ chmod 777 $BUILD_DIR


Cache "webapp-cache: web/node_modules": Downloading
Cache "webapp-cache: web/node_modules": Not found

Default variables:
BITBUCKET_BUILD_NUMBER
BITBUCKET_CLONE_DIR
BITBUCKET_COMMIT
BITBUCKET_GIT_HTTP_ORIGIN
BITBUCKET_GIT_SSH_ORIGIN
BITBUCKET_PARALLEL_STEP
BITBUCKET_PARALLEL_STEP_COUNT
BITBUCKET_PIPELINE_UUID
BITBUCKET_PROJECT_KEY
BITBUCKET_PROJECT_UUID
BITBUCKET_REPO_FULL_NAME
BITBUCKET_REPO_IS_PRIVATE
BITBUCKET_REPO_OWNER
BITBUCKET_REPO_OWNER_UUID
BITBUCKET_REPO_SLUG
BITBUCKET_REPO_UUID
BITBUCKET_SSH_KEY_FILE
BITBUCKET_STEP_RUN_NUMBER
BITBUCKET_STEP_TRIGGERER_UUID
BITBUCKET_STEP_UUID
BITBUCKET_WORKSPACE
CI
DOCKER_HOST
PIPELINES_JWT_TOKEN

Workspace variables:
ACR_PASSWORD
ACR_USERNAME
BITBUCKET_APP_PASSWORD_SERHAT
BITBUCKET_USER_NAME
CICD_SCRIPT_PASS
DEPLOYMENT_PASS
RV_CICD
RV_CICD_SERVER
RV_DEVOPS
RV_DEVOPS_SERVER
RV_TEST
RV_TEST_SERVER
RV_UAT
RV_UAT_SERVER
SEF_PROD
SEF_PROD_SERVER
SEF_TEST
SEF_TEST_SERVER
SENTRY_CLI_TOKEN

Repository variables:
SEF_DEDICATED
SEF_DEDICATED_SERVER

Images used:
build : docker.io/$ACR_USERNAME/reanode@sha256:c5e0f947c23214ea72a882990893776a0b1cdf1a0b8a4b9e96be0300c44b8659
+ chmod 777 https://bitbucket.org/reaventures-devcenter/xxx-solution/src/3e0f90bdc0479ac45cd09243e7965818f8394183/scripts/ci/pipe/common/build.sh

+ if [[ ${BITBUCKET_BRANCH} == @(bugfix/SEF-*|feature/SEF-*|hotfix/SEF-*|develop) ]]
then 
https://bitbucket.org/reaventures-devcenter/xxx-solution/src/3e0f90bdc0479ac45cd09243e7965818f8394183/scripts/ci/pipe/common/build.sh webapp test

elif [ ${BITBUCKET_BRANCH} == "master" ]
then
https://bitbucket.org/reaventures-devcenter/xxx-solution/src/3e0f90bdc0479ac45cd09243e7965818f8394183/scripts/ci/pipe/common/build.sh webapp prod
fi


bash: [: ==: unary operator expected
Assembling contents of new cache 'webapp-cache'
Cache "webapp-cache: web/node_modules": Skipping upload for empty cache

Searching for files matching artifact pattern web/dist/xxx-web/*.zip

Searching for test report files in directories named [test-results, failsafe-reports, test-reports, TestResults, surefire-reports] down to a depth of 4
Finished scanning for test reports. Found 0 test report files.
Merged test suites, total number tests is 0, with 0 failures and 0 errors.

[Theodora Boudale]

Hi @serhatakbak,

Thank you for sharing the build log. I can see now what is happening for this step.

In the step's script, you are using the variable BITBUCKET_BRANCH in an if statement. When a branch pipeline is triggered automatically because of commits you pushed to a branch, this specific branch gets cloned in the Docker container where the step is running and the variable BITBUCKET_BRANCH has as value the name of the branch.

However, when you run a Pipelines build on a commit (and not on a branch), the variable BITBUCKET_BRANCH is empty. If you look at the build setup in the beginning on the log, you can see that the commit you run the build for is checkout out and the clone in the Docker container where the step is running is in a 'detached HEAD' state:

git checkout 3e0f90bdc0479ac45cd09243e7965818f8394183
Note: switching to '3e0f90bdc0479ac45cd09243e7965818f8394183'.

You are in 'detached HEAD' state.

Since BITBUCKET_BRANCH is empty, none of the two conditions in the if statements are true. The reason for the error

bash: [: ==: unary operator expected

is that the condition in elif is enclosed in single brackets instead of double ones. You can read more about this here:

https://linuxconfig.org/bash-script-unary-operator-expected

You can enclose the condition ${BITBUCKET_BRANCH} == "master" in double brackets to prevent this error. Please keep in mind that if you trigger this pipeline on a commit, none of the conditions will be true regardless of single or double brackets since BITBUCKET_BRANCH will be empty.

The reason that the step and build do not fail is that the statement returns a zero exit code. A Pipelines step will fail when a command returns a non-zero exit code, which does not happen in this case.

If you have a Pipelines build with a different script where the same error occurs, please feel free to post the build log here and I can take a look.

With regards to caching not working as expected: if this concerns this specific step, and if the cache directory content is generated by one of the commands in the if statements, it is expected to be empty since none of these commands get executed.

If you have any questions, please feel free to reach out.

Kind regards,
Theodora

[serhatakbak]

Thanks for debugging, contributions and feedbacks. Now, everything is crystal clear for us

Best!

[Theodora Boudale]

You are very welcome!

Please feel free to reach out if you ever need anything else!

Kind regards,
Theodora

[serhatakbak]

BTW, the issue doesn't relate to build steps only but all others; the strange thing is that pipelines continues to next step without any failure with the same message, "bash: [: ==: unary operator expected"