Answers: <p>This come from a design choice of YAML language about <a href="http://yaml.org/type/bool.html" rel="noreferrer">booleans</a></p>
  <p>Every unquoted value matching this &quot;regex&quot;:</p>
  <pre><code> y|Y|yes|Yes|YES|n|N|no|No|NO
  |true|True|TRUE|false|False|FALSE
  |on|On|ON|off|Off|OFF
  </code></pre>
  <p>Will be converted to <code>True</code>  or <code>False</code>. Note that from <a href="https://yaml.org/spec/1.2.2/#10212-boolean" rel="noreferrer">YAML 1.2</a> and onwards it appears that only <code>true</code> and <code>false</code> will be interpreted as boolean values.</p>
  <p>This start causing a problem when your code will test an environment value to be yes or no for example taking this script (other examples <a href="https://github.com/docker/compose/pull/2000#issuecomment-138676720" rel="noreferrer">in the PR discution</a>):</p>
  <pre><code>if [ &quot;$SOME_VAR&quot; == &quot;yes&quot; ];
  then
    echo &quot;Variable SOME_VAR is activated&quot;
  else
    echo &quot;Variable SOME_VAR is NOT activated&quot;
  fi
  </code></pre>
  <p>And setting in your compose file</p>
  <pre><code>environment:
    SOME_VAR: yes
  </code></pre>
  <p>Will result in <code>SOME_VAR</code> being <code>True</code> when the script run, hence taking the wrong case as it is not equal to <code>yes</code>.</p>
  <p>So the choice <a href="https://github.com/docker/compose/issues/1788" rel="noreferrer">has been made</a> to <a href="https://github.com/docker/compose/pull/2000" rel="noreferrer">disallow boolean</a> to prevent unwanted behaviors hard to debug when you're not aware of the YAML rule.</p>
  <p>I see two way to get over the problem:</p>
  <ol>
  <li><p>Using an <a href="https://docs.docker.com/compose/compose-file/compose-file-v1/#envfile" rel="noreferrer"><code>env_file</code></a> instead, they are not parsed IIRC and should prevent the conversion.</p>
  </li>
  <li><p>As you already said, use a wrapper script around your launcher to define the value instead before launching the app, something along the line of this should do:</p>
  <pre><code> AUTOAPPLY=false
   if [ &quot;$SOME_VAR&quot; == &quot;true&quot; ]
   then
       AUTOAPPLY=true
   fi
  
   ./target/universal/stage/bin/APPNAME -Dplay.evolutions.db.default.autoApply=$AUTOAPPLY
  </code></pre>
  </li>
  </ol>
  
Answers: CC BY-SA 4.0
Answers: 2022-06-25T07:43:29.933Z
Answers: change yaml 1.2.2 boolean only (true|false) https://yaml.org/spec/1.2.2/#10212-boolean
Answers: seunggabi
Answers: CC BY-SA 4.0
Answers: 2022-06-25T17:11:37.533Z
Answers: There's already a note about that in the answer
Answers: Tensibai
Answers: CC BY-SA 4.0
Answers: 2017-03-17T08:54:40.677Z
Answers: 2022-02-22T05:25:01.107Z
Answers: 2022-02-22T05:25:01.107Z
Answers: Tensibai
Answers: <p>double quotes worked for me. Example:</p>
  <pre><code>environment:
    MY_VAR: &quot;true&quot;
  </code></pre>
  
Answers: CC BY-SA 4.0
Answers: 2022-04-12T10:27:54.597Z
Answers: 2022-04-12T10:27:54.597Z
Answers: Alexey Kolesaev
Answers: <p>That's YAML. It interprets <code>true</code> as a boolean. Envars must be strings, hence the requirement to make the type explicit via quotes.</p>
  
  <p>Test this out with <a href="https://www.json2yaml.com/" rel="noreferrer">https://www.json2yaml.com/</a></p>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-18T21:47:20.420Z
Answers: More generally, the quotes won't appear in the value itself because they are YAML formatting.
Answers: coderanger
Answers: CC BY-SA 3.0
Answers: 2017-03-17T06:48:57.857Z
Answers: 2017-03-17T06:48:57.857Z
Answers: Assaf Lavie
Body: <p>Defining a boolean in a docker-compose.yml file:</p>
  
  <pre><code>environment:
    SOME_VAR: true
  </code></pre>
  
  <p>and running <code>docker up</code> results in:</p>
  
  <pre><code>contains true, which is an invalid type, it should be a string, number, or a null
  </code></pre>
  
  <p><strong>Attempts to solve the issue</strong></p>
  
  <ol>
  <li>If true is changed to True the issue persists.</li>
  <li><p>Using <code>'true'</code> is not accepted by the code itself (<a href="https://www.playframework.com/" rel="noreferrer">a play framework app</a> is started using the <code>./target/universal/stage/bin/APPNAME -Dplay.evolutions.db.default.autoApply=</code>, i.e. either <code>-Dplay.evolutions.db.default.autoApply=true</code> or <code>-Dplay.evolutions.db.default.autoApply=false</code> parameter):</p>
  
  <p>VAR has type STRING rather than BOOLEAN</p></li>
  <li><p>Using <code>yes</code> or <code>no</code> as a variable results in:</p>
  
  <p>contains true, which is an invalid type, it should be a string, number, or a null</p></li>
  <li><p>Using <code>yes</code> and using a script that transforms <code>yes</code> to true works</p></li>
  </ol>
  
  <p><strong>Discussion</strong></p>
  
  <p><a href="https://docs.docker.com/compose/compose-file/compose-file-v1/#entrypoint" rel="noreferrer">According the docs</a> <code>Any boolean values; true, false, yes no, need to be enclosed in quotes to ensure they are not converted to True or False by the YML parser</code>:</p>
  
  <blockquote>
    <p><strong>Environment</strong></p>
    
    <p>Add environment variables. You can use either an array or a
    dictionary. Any boolean values; true, false, yes no, need to be
    enclosed in quotes to ensure they are not converted to True or False
    by the YML parser.</p>
    
    <p>Environment variables with only a key are resolved to their values on
    the machine Compose is running on, which can be helpful for secret or
    host-specific values.</p>
  
  <pre><code>environment:
    RACK_ENV: development
    SHOW: 'true'
    SESSION_SECRET:
  
  environment:
    - RACK_ENV=development
    - SHOW=true
    - SESSION_SECRET
  </code></pre>
  </blockquote>
  
  <p><strong>Question</strong></p>
  
  <p>Why is it not allowed?</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-03-16T17:20:59.340Z
Comments: Not about DevOps? `DevOps Stack Exchange is a question and answer site for software engineers working on automated testing, continuous delivery, service integration and monitoring, and building SDLC infrastructure`
Comments: 030
Comments: CC BY-SA 3.0
Comments: 2017-03-16T17:28:54.773Z
Comments: @Aurora0001 question updated
Comments: 030
Comments: CC BY-SA 4.0
Comments: 2022-05-03T07:36:52.690Z
Comments: try `SOME_VAR: "true"` or `SOME_VAR: 1` if this works for you
Comments: rubo77
Tags: <docker-compose>
Title: Why is one not allowed to use a Boolean in a docker-compose.yml?
UserDisplayName: 030
ThreadText: # Why is one not allowed to use a Boolean in a docker-compose.yml?
  
  (Asked by: username_0 on 2017-03-16)
  
  Defining a boolean in a docker-compose.yml file:
  
  ```
  environment:
    SOME_VAR: true
  
  ```
  
  and running `docker up` results in:
  
  ```
  contains true, which is an invalid type, it should be a string, number, or a null
  
  ```
  
  **Attempts to solve the issue**
  
  1. If true is changed to True the issue persists.
  2. Using `'true'` is not accepted by the code itself ([a play framework app](https://www.playframework.com/) is started using the `./target/universal/stage/bin/APPNAME -Dplay.evolutions.db.default.autoApply=`, i.e. either `-Dplay.evolutions.db.default.autoApply=true` or `-Dplay.evolutions.db.default.autoApply=false` parameter):
  
     VAR has type STRING rather than BOOLEAN
  3. Using `yes` or `no` as a variable results in:
  
     contains true, which is an invalid type, it should be a string, number, or a null
  4. Using `yes` and using a script that transforms `yes` to true works
  
  **Discussion**
  
  [According the docs](https://docs.docker.com/compose/compose-file/compose-file-v1/#entrypoint) `Any boolean values; true, false, yes no, need to be enclosed in quotes to ensure they are not converted to True or False by the YML parser`:
  
  > **Environment**
  >
  > Add environment variables. You can use either an array or a
  > dictionary. Any boolean values; true, false, yes no, need to be
  > enclosed in quotes to ensure they are not converted to True or False
  > by the YML parser.
  >
  > Environment variables with only a key are resolved to their values on
  > the machine Compose is running on, which can be helpful for secret or
  > host-specific values.
  >
  > ```
  > environment:
  >   RACK_ENV: development
  >   SHOW: 'true'
  >   SESSION_SECRET:
  >
  > environment:
  >   - RACK_ENV=development
  >   - SHOW=true
  >   - SESSION_SECRET
  >
  > ```
  
  **Question**
  
  Why is it not allowed?
  
  **Tags:** docker-compose
  
  > **Comments:**
  > **username_0**: Not about DevOps? `DevOps Stack Exchange is a question and answer site for software engineers working on automated testing, continuous delivery, service integration and monitoring, and building SDLC infrastructure`  
  > **username_0**: @Aurora0001 question updated  
  > **username_1**: try `SOME_VAR: "true"` or `SOME_VAR: 1` if this works for you  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_2 on 2017-03-17. Score: 32 | Accepted answer
  
  This come from a design choice of YAML language about [booleans](http://yaml.org/type/bool.html)
  
  Every unquoted value matching this "regex":
  
  ```
   y|Y|yes|Yes|YES|n|N|no|No|NO
  |true|True|TRUE|false|False|FALSE
  |on|On|ON|off|Off|OFF
  
  ```
  
  Will be converted to `True` or `False`. Note that from [YAML 1.2](https://yaml.org/spec/1.2.2/#10212-boolean) and onwards it appears that only `true` and `false` will be interpreted as boolean values.
  
  This start causing a problem when your code will test an environment value to be yes or no for example taking this script (other examples [in the PR discution](https://github.com/docker/compose/pull/2000#issuecomment-138676720)):
  
  ```
  if [ "$SOME_VAR" == "yes" ];
  then
    echo "Variable SOME_VAR is activated"
  else
    echo "Variable SOME_VAR is NOT activated"
  fi
  
  ```
  
  And setting in your compose file
  
  ```
  environment:
    SOME_VAR: yes
  
  ```
  
  Will result in `SOME_VAR` being `True` when the script run, hence taking the wrong case as it is not equal to `yes`.
  
  So the choice [has been made](https://github.com/docker/compose/issues/1788) to [disallow boolean](https://github.com/docker/compose/pull/2000) to prevent unwanted behaviors hard to debug when you're not aware of the YAML rule.
  
  I see two way to get over the problem:
  
  1. Using an [`env_file`](https://docs.docker.com/compose/compose-file/compose-file-v1/#envfile) instead, they are not parsed IIRC and should prevent the conversion.
  2. As you already said, use a wrapper script around your launcher to define the value instead before launching the app, something along the line of this should do:
  
     ```
      AUTOAPPLY=false
      if [ "$SOME_VAR" == "true" ]
      then
          AUTOAPPLY=true
      fi
  
      ./target/universal/stage/bin/APPNAME -Dplay.evolutions.db.default.autoApply=$AUTOAPPLY
  
     ```
  
  > **Comments:**
  > **username_3**: change yaml 1.2.2 boolean only (true|false) https://yaml.org/spec/1.2.2/#10212-boolean  
  > **username_2**: There's already a note about that in the answer  
  
  ---
  
  ### Answer by username_5 on 2017-03-17. Score: 11
  
  That's YAML. It interprets `true` as a boolean. Envars must be strings, hence the requirement to make the type explicit via quotes.
  
  Test this out with <https://www.json2yaml.com/>
  
  > **Comments:**
  > **username_6**: More generally, the quotes won't appear in the value itself because they are YAML formatting.  
  
  ---
  
  ### Answer by username_4 on 2022-04-12. Score: 4
  
  double quotes worked for me. Example:
  
  ```
  environment:
    MY_VAR: "true"
  
  ```
  
  
  ---
  
  