Error when setting Integer ENV variables in gdk.yml

Overview

Setting integer env variables in gdk.yml does not work. You have to wrap it in string quotes. I think GDK should accept integer variables without needing to be wrapped in quotes.

# you have to set integer variables this way
env:
  GITLAB_SIMULATE_SAAS: "1"

# currently this is not acceptable but I think it should be
env:
  GITLAB_SIMULATE_SAAS: 1

Details

I followed what's indicated in the guide and set my environment variables in gdk.yml instead of env.runit since it seems GDK was no longer reading variables in env.runit.

This is my environment variables in gdk.yml:

env:
  GITLAB_LICENSE_MODE: "test"
  CUSTOMER_PORTAL_URL: "https://customers.staging.gitlab.com"
  CLOUD_CONNECTOR_SELF_SIGN_TOKENS: 1
  GITLAB_SIMULATE_SAAS: 1
  AI_GATEWAY_URL: "http://gdk.test:5052"

When starting up Rails (in this case Rails Console), I get this error:

/Users/pamartiaga/Code/gdk/lib/gdk/command/rails.rb:18:in `exec': no implicit conversion of Integer into String (TypeError)


        from /Users/pamartiaga/Code/gdk/lib/gdk/command/rails.rb:18:in `execute_command!'
        from /Users/pamartiaga/Code/gdk/lib/gdk/command/rails.rb:12:in `run'
        from /Users/pamartiaga/Code/gdk/lib/gdk/command.rb:80:in `block in run'
        from /Users/pamartiaga/Code/gdk/lib/gdk/telemetry.rb:38:in `with_telemetry'
        from /Users/pamartiaga/Code/gdk/lib/gdk/command.rb:81:in `run'
        from /Users/pamartiaga/Code/gdk/lib/gdk.rb:65:in `block in main'
        from /Users/pamartiaga/.local/share/mise/installs/ruby/3.3.9/lib/ruby/gems/3.3.0/gems/bundler-2.7.1/lib/bundler.rb:409:in `block in with_unbundled_env'
        from /Users/pamartiaga/.local/share/mise/installs/ruby/3.3.9/lib/ruby/gems/3.3.0/gems/bundler-2.7.1/lib/bundler.rb:698:in `with_env'
        from /Users/pamartiaga/.local/share/mise/installs/ruby/3.3.9/lib/ruby/gems/3.3.0/gems/bundler-2.7.1/lib/bundler.rb:409:in `with_unbundled_env'
        from /Users/pamartiaga/Code/gdk/lib/gdk.rb:59:in `main'
        from /Users/pamartiaga/.local/share/mise/installs/ruby/3.3.9/lib/ruby/gems/3.3.0/gems/gitlab-development-kit-0.2.19/bin/gdk:30:in `run'
        from /Users/pamartiaga/.local/share/mise/installs/ruby/3.3.9/lib/ruby/gems/3.3.0/gems/gitlab-development-kit-0.2.19/bin/gdk:85:in `<top (required)>'
        from /Users/pamartiaga/.local/share/mise/installs/ruby/3.3.9/lib/ruby/site_ruby/3.3.0/rubygems.rb:319:in `load'
        from /Users/pamartiaga/.local/share/mise/installs/ruby/3.3.9/lib/ruby/site_ruby/3.3.0/rubygems.rb:319:in `activate_and_load_bin_path'
        from /Users/pamartiaga/.local/share/mise/installs/ruby/3.3.9/bin/gdk:36:in `<main>'

I have to wrap the Integer environment variables in string quotes in order to avoid the error, ie:

env:
  GITLAB_LICENSE_MODE: "test"
  CUSTOMER_PORTAL_URL: "https://customers.staging.gitlab.com"
  CLOUD_CONNECTOR_SELF_SIGN_TOKENS: "1"
  GITLAB_SIMULATE_SAAS: "1"
  AI_GATEWAY_URL: "http://gdk.test:5052"

Implementation

The issue occurs because Ruby's exec method requires all environment variable values to be strings, but YAML parses unquoted numeric values as integers. When GDK.config.env contains integer values and is passed to exec in lib/gdk/command/rails.rb:18, it raises a TypeError.

Steps to fix:

  1. Option1 : Modify the env hash_setting in lib/gdk/config.rb to ensure all values are converted to strings when the hash is accessed. This can be done by adding a transformation that calls .to_s on all hash values.
  2. Option2 : Alternative approach: Create a helper method that wraps GDK.config.env and ensures all values are stringified before being passed to exec. This method could be added to the config class or as a utility method.
  3. Option 3: Update the hash_setting implementation in lib/gdk/config_settings.rb to support an optional stringify_values: true parameter that automatically converts all hash values to strings.
  4. Add tests to verify that:
    • Integer values in gdk.yml env section are properly converted to strings
    • Boolean values (true/false) are also handled correctly
    • Existing string values continue to work
    • Floating point values are converted appropriately
  5. Consider edge cases:
    • Boolean values (true/false) should be converted to "true"/"false"
    • Null values should be handled appropriately
    • Nested structures (if supported) should be handled or explicitly rejected

The recommended approach is option 3, as it provides a reusable solution that can be applied to other hash settings that may have similar requirements.

Impacted categories

The following categories relate to this issue:

Edited by Mohga Gamea