Orb-level parameters

Are there ways to set a parameter that affects the behavior of the entire orb?

For example, let’s say I have 5 workflow steps that all override the cache-key with the same value. I would have to set that parameter on each of those, right?

Additionally, it might be nice to invoke an orb once with a top level param that influences the behavior of other commands. For example, a node orb, being able to set whether npm or yarn is the package manager might be a better way of influencing defaults (see, e.g., discussion in https://github.com/CircleCI-Public/circleci-orbs/pull/85)

2 Likes

@wyardley This is good food for thought!

I know that the team is currently sketching out ideas for some kind of top-level concept of orb parameters—i.e., defining parameters for an entire orb, which would then filter down and/or influence the behavior of individual parameters in commands/jobs.

Good to know that we’re on the right track :slight_smile:

1 Like

Glad to see this issue already raised!

I would like to submit my use-case for this feature.

I have some config like this:

  python: dialogue/sandbox@dev:python
  app: dialogue/sandbox@dev:lambda-python

workflows:
  main:
    jobs:
      - python/pylama:
          name: pylama
          executor:
            name: python/python3_6
            version: "3.6"
      - python/isort:
          name: isort
          executor:
            name: python/python
            version: "3.6"
          context: org-global-v2
      - python/black:
          name: black
          executor:
            name: python/python
            version: "3.6"
          context: org-global-v2
      - app/deploy:
          name: deploy
          context: org-global-v2
          executor:
            name: python/python
            version: "3.6"

But I wish I could something like this:

  python: dialogue/sandbox@dev:python
  app:
    from: dialogue/sandbox@dev:lambda-python
    python_version: 3.6

workflows:
  main:
    jobs:
      - python/pylama:
          name: pylama
      - python/isort:
          name: isort
          context: org-global-v2
      - python/black:
          name: black
          context: org-global-v2
      - app/deploy:
          name: deploy
          context: org-global-v2

Also… while I’m here, although off-topic, I really wish CCI would apply a default context and/or allow something like:

workflows:
  default_context: org-global-v2
  main:
    jobs:
      - python/pylama:
          name: pylama
      - python/isort:
          name: isort
      - python/black:
          name: black
      - app/deploy:
          name: deploy
1 Like

Has there been any movement on this? I would also love to have orb-level parameters, particularly for version parameters that should be consistent across commands.

Hi there! Is some progress on this topic? It may be useful for those developers who work on huge projects with big amounts of repos