[semver:patch] Boolean parameters not working

[charlescqian]

Orb version

3.0.0

What happened

Trying to set any of the boolean parameters does not work. Affected parameters (All boolean parameters):

• block-workflow
• dont-quit
• force-cancel-previous
• include-debug
• this-branch-only

Orb parameter dont-quit is set to true, letting this job proceed! is always shown even if dont-quit is set to false explicitly

Seems like CircleCI's booleans are passed as 0/1, so when trying to cast the boolean parameters as string, if [ "${DONT_QUIT}" != "false" ];then will always be true Ex. when dont-quit: true, I see DONT_QUIT=1 in the job's logs, and vice versa for dont-quit: false, I'm seeing DONT_QUIT=0

Default block-workflow is true but Block: 0 is shown in the logs.

As a result, when a build exceeds the max wait time, it will always fail as force-cancel-previous is not yet implemented, instead of cancelling the build.

Expected behavior

Boolean parameters are passed and working properly. By default, dont-quit should be false and builds should be cancelling instead of failing if the max-wait-time is exceeded.

[eddiewebb]

Are you using the job or command? How booleans are handled depends on shell.

On Tue, Feb 20, 2024, 2:55 PM Charles Qian @.***> wrote:

Orb version

3.0.0 What happened

Trying to set any of the boolean parameters does not work. Affected parameters (All boolean parameters):

• block-workflow
• dont-quit
• force-cancel-previous
• include-debug
• this-branch-only

Orb parameter dont-quit is set to true, letting this job proceed! is always shown even if dont-quit is set to false explicitly

Seems like CircleCI's booleans are passed as 0/1, so when trying to cast the boolean parameters as string, if [ "${DONT_QUIT}" != "false" ];then will always be true Ex. when dont-quit: true, I see DONT_QUIT=1 in the job's logs, and vice versa for dont-quit: false, I'm seeing DONT_QUIT=0

Default block-workflow is true but Block: 0 is shown in the logs.

As a result, when a build exceeds the max wait time, it will always fail as force-cancel-previous is not yet implemented, instead of cancelling the build. Expected behavior

Boolean parameters are passed and working properly. By default, dont-quit should be false and builds should be cancelling instead of failing if the max-wait-time is exceeded.

— Reply to this email directly, view it on GitHub https://github.com/eddiewebb/circleci-queue/issues/114, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIEWSQJPBFGZ3UJHWFGJ5TYUT5RTAVCNFSM6AAAAABDRYSXI6VHI2DSMVQWIX3LMV43ASLTON2WKOZSGE2DKMJVHA2TAOI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[eddiewebb]

My understanding is that circleci config process is same behavior as our processor, and the result for env below, true/false are preserved at this point.

        environment:
          BLOCK_WORKFLOW: true
          CCI_API_KEY_NAME: CIRCLECI_API_KEY
          CIRCLECI_BASE_URL: https://circleci.com
          CONFIDENCE_THRESHOLD: '1'
          DEBUG: true
          DONT_QUIT: false
          FILTER_BRANCH: false
          FORCE_CANCEL_PREVIOUS: false
          JOB_REGEXP: ''
          MAX_TIME: '10'
          MY_BRANCH: $CIRCLE_BRANCH
          MY_PIPELINE_NUMBER: 1
          ONLY_ON_BRANCH: master
          ONLY_ON_WORKFLOW: '*'
          TAG_PATTERN: ''

Unfortunately docs only say

Boolean values may be returned as a ‘1’ for True and ‘0’ for False.

and no indicator or where or when it may not....

But my past experience is that it was shell dependent (ash, zsh, bsh) - and I am trying to run some confirmation testing.

[eddiewebb]

My orb's image, cimg/base:stable and an older cimg\node:14 image both preserve and consider the booleans as well.

https://app.circleci.com/pipelines/github/eddiewebb/circleci-samples/501/workflows/868a02ee-2866-4c4b-9505-2684ae1ce01c

So I have to think those folks seeing non true/false values like @charlescqian are using the command on a non cimg variant, which is cool but need to isolate to fix in a way that wont break default executor.

If folks are seeing this on default executor then I'm a bit stumped as to what differs and would need to probe further

[charlescqian]

@eddiewebb Thanks for the reply! I am using the until_front_of_line command and running on cimg/node:18.13

[eddiewebb]

🤯 - different behavor at job and command

You can see when we set ENV_VAR to yaml value at job level it's preserved (true/falsae) but when we set identically at command level it is not.

(this does not use orb, just general behavior)

[eddiewebb]

After much debate I landed on this model - set my own envars!

    steps:
      - run: echo "export DEBUG=<<parameters.default_true>> >> $BASH_ENV"
      - run: 
          shell: bash
          name: reused command
          command: |
            set
            if [ "${DEBUG}" == "true" ] ;then
              echo "DEBUG"
            fi

This works in standalone reuse xconsistently, so applying to orb and will have a RC soon.

[eddiewebb]

@charlescqian eddiewebb/queue@dev:526 uses its own step to set environment variables, and this seems to preserve them as true/false strings without any yaml or golang interpretation.

[charlescqian]

@charlescqian eddiewebb/queue@dev:526 uses its own step to set environment variables, and this seems to preserve them as true/false strings without any yaml or golang interpretation.

Sweet, thank you!

[eddiewebb]

Fixed by #117 and published as 3.1.1