<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>

CC BY-SA 4.0
2022-06-25T07:43:29.933Z
change yaml 1.2.2 boolean only (true|false) https://yaml.org/spec/1.2.2/#10212-boolean
seunggabi
CC BY-SA 4.0
2022-06-25T17:11:37.533Z
There's already a note about that in the answer
Tensibai
CC BY-SA 4.0
2017-03-17T08:54:40.677Z
2022-02-22T05:25:01.107Z
2022-02-22T05:25:01.107Z
Tensibai
<p>double quotes worked for me. Example:</p>
<pre><code>environment:
  MY_VAR: &quot;true&quot;
</code></pre>

CC BY-SA 4.0
2022-04-12T10:27:54.597Z
2022-04-12T10:27:54.597Z
Alexey Kolesaev
<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>

CC BY-SA 3.0
2017-03-18T21:47:20.420Z
More generally, the quotes won't appear in the value itself because they are YAML formatting.
coderanger
CC BY-SA 3.0
2017-03-17T06:48:57.857Z
2017-03-17T06:48:57.857Z
Assaf Lavie
<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>

CC BY-SA 3.0
2017-03-16T17:20:59.340Z
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`
030
CC BY-SA 3.0
2017-03-16T17:28:54.773Z
@Aurora0001 question updated
030
CC BY-SA 4.0
2022-05-03T07:36:52.690Z
try `SOME_VAR: "true"` or `SOME_VAR: 1` if this works for you
rubo77
<docker-compose>
Why is one not allowed to use a Boolean in a docker-compose.yml?
030
# 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

If true is changed to True the issue persists.
Using 'true' is not accepted by the code itself (a play framework app 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
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
Using yes and using a script that transforms yes to true works

Discussion
According the docs 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
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 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):
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 to disallow boolean 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:

Using an env_file instead, they are not parsed IIRC and should prevent the conversion.

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"


---

