CircleCI-Public / shellcheck-orb

An orb for ShellCheck, a static analysis tool for shell scripts (https://shellcheck.net) — check all scripts in your repository on every commit
https://circleci.com/developer/orbs/orb/circleci/shellcheck
MIT License
19 stars 26 forks source link

Create an executor parameter to allow for custom executors #58

Open jenny-miggin opened 1 year ago

jenny-miggin commented 1 year ago

Describe Request:

A static executor is currently defined in the check job, but this does not allow for any executor customisations. Allow for a custom executor to be used in place of this, if required

Examples:

Sample future config:

version: 2.1

orbs:
  shellcheck: circleci/shellcheck@3.1.3

executors:
  my-small-executor:
    docker:
      - image: cimg/base:stable
    resource_class: small

workflows:
  my_workflow:
    jobs:
      - shellcheck/check:
          dir: ./myScripts
          exclude: SC2148
          executor: my-small-executor

Supporting Documentation Links:

n/a

nmiyake commented 1 week ago

Adding agreement here. Another issue/scenario is that, on a CircleCI Enterprise install, I've run into issues where we're hitting image pull limits for the cimg/base image. Normally, we would handle this by mirroring the image in an internal registry and pulling from there instead, but the fact that the executor/base image is not configurable makes this not possible with the current structure of the orb.

nmiyake commented 1 week ago

I took a look at implementing this, but believe that doing so would require/introduce a backcompat break.

The issue I run into is that if executor is added as a parameter, a default can be set, but that default must be a static value, and this would break current uses cases where callers specify a value for image-tag.

Semantically, for backcompat, it would be necessary for the default value of executor to pass through the parameter provided to image-tag, but I don't think that's possible in the current manner that orbs are defined. As such, introducing executor as a parameter would require either breaking backcompat for the job or introducing a new version of the job that takes this parameter.

However, will note that is both #64 and #56 are resolved, that would "solve" the specific issue brought up here -- even though the executor couldn't be specified as a parameter, the image name and resource type could still be configured.