Open jenny-miggin opened 1 year 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.
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.
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 requiredExamples:
Sample future config:
Supporting Documentation Links:
n/a