Custom parameter issue with circleci_ip_ranges param

API
1

Hey there, I am trying to update a custom orb to default to circleci_ip_ranges: false but allow for the jobs calling the orb to set to true as needed (internal access to a GKE kubernetes resource). The param im creating is causing the following validating error:
expected type: Boolean, found: String

Here is an example config and commands that is production this error:

description: Example job file

parameters:
  executor:
    type: enum
    enum: [ 'default', 'custom' ]
    default: 'default'
    description: 'The executor to use for the job'
  cip:
    type: boolean
    default: false
    description: 'Enable CircleCI jobs to go through a set of well-defined IP address ranges: https://circleci.com/docs/ip-ranges/'

executor: <<parameters.executor>>
circleci_ip_ranges: <<parameters.cip>>

steps:
  - clean-checkout

circleci orb validate --skip-update-check example.txt  
Error: ERROR IN CONFIG FILE:
[#/jobs] 4 schema violations found
Any string key is allowed as job name.
1. [#/jobs/example] 0 subschemas matched instead of one
|   1. [#/jobs/example] only 1 subschema matches out of 2
|   |   1. [#/jobs/example/circleci_ip_ranges] expected type: Boolean, found: String
|   |   |   SCHEMA:
|   |   |     type: boolean
|   |   |   INPUT:
|   |   |     <<parameters.cip>>
|   2. [#/jobs/example] expected type: String, found: Mapping
|   |   Job may be a string reference to another job

Any guidance would be great here.

2

It is a known limitation of circleci_ip_ranges

3

It is a known limitation of circleci_ip_ranges

Can you expand on why you believe this is true? The blurb you quoted does not indicate any sort of known limitation.

To me, this seems like a problem with the parsing of the yaml, though the indicated yaml certainly matches the documentation for specifying a boolean parameter:

commands:
  npm-install:
    parameters:
      clean:
        description: Perform a clean install
        type: boolean
        default: false
4

If you read the replies you will find a post by

sebastian-lerner CircleCI Employee Dec 2021

Where he states

We’ve found the root cause and want to let you know that this is currently a known limitation that we’re working on fixing. I’ll provide an update when I have more.

Currently, the main CircleCI docs refer to this same thread, so it is unlikely that anything has been changed.

There is nothing wrong with the way you have expressed things at the yaml level. The limitation is within the code based that operates based on what is expressed by the yaml.