Passing string environmental as parameters in API v2 with continuation orb

Hi. I need to have a pipeline that I can trigger manually via API v2 and send from API some environmental variables as parameters. I have something like this in my config.yml

version: 2.1

setup: true


parameters:
    trigger_process_api:
      type: boolean
      default: false
    some_name:
      type: string
      default: ""
orbs:
  path-filtering: circleci/path-filtering@0.0.3
  continuation: circleci/continuation@0.1.2


workflows:
  setup:
    unless: << pipeline.parameters.trigger_process_api >>
    jobs:
      - path-filtering/filter:
          base-revision: main
          mapping: |
            some_dir/.* trigger_some_workflow true
          config-path: .circleci/workflows.yml
  trigger_process_api:
    when: << pipeline.parameters.trigger_process_api >>
    jobs:
      - continuation/continue:
          pre-steps:
            - checkout
          configuration_path: .circleci/workflows.yml
          parameters: '{"trigger_process": true, "some_name": ""}'

my .circleci/workflow.yml is looking like that:

version: 2.1

parameters:
  some_name:
    type: string
    default: fillme
  trigger_process:
    type: boolean
    default: false
  trigger_process_api:
    type: boolean
    default: false

jobs:
  docker:
    -some_image
  steps:
  - run:
      name: run script with some_name env
      command: |
        echo "$some_name"

I need to pass the parameter as an environmental variable from API through config.yml and continuation orb to workflow.yml. Is this even possible?

trigger trigger_process_api is working fine, but the some_name isn’t working correctly.

some_name is a passed parameter, rather than an environment variable so you would access it with

 <<pipline.parameters.some_name>>

rather than

 $some_name

@rit1010
Where should I put this in my script?:

 <<pipline.parameters.some_name>>

In your example where you have placed $Some_name in the command: statement

It’s now working.
I get error:
{“message”:“Conflicting pipeline parameters.”}

OK, this is where my knowledge ends as I’ve not got to the point of needing to call additional .yml files and so I do not know what level of isolation there is between them, in terms of parameter naming.

Can you try the following - rename the some_name parameter in the workflow.yml file to something that does not exist in the config.yml file. The logic being is that you may be defining a parameter that is accessible in both script files in 2 places, which is only ‘discovered’ when you try and access a value.