Config processing is an area where small changes can have a large impact across our customer base. We do our best, through extensive unit, functional, and regression testing to make sure that we don’t break config processing. But sometimes we find bugs where the implementation is not conforming to specification and our regression testing tells us that there are a small number of people who will be affected by the bug fixes.
The following bugfixes will be going live next week. We have reached out to people our regression testing has shown will be affected but since we don’t test every single config some of you may encounter these stricter errors without having been contacted.
Explicit null as default value is no longer accepted
We fixed a bug where a null default value for a parameter was accepted as a valid default. Parameters declared with a null default value will now always need to be passed in invocations. The following will no longer be accepted:
jobs:
my-job:
machine: true
parameters:
foo:
type: string
default:
steps:
- ...
workflows:
my-workflow:
jobs:
- my-job # this will error, the `foo` parameter must be passed
An error will be reported:
Error calling workflow: 'my-workflow'
Error calling job: 'my-job'
Missing required argument(s): foo"
No more extra arguments to jobs/executors/commands
The compiler is stricter about passing extra arguments that don’t match formal parameters to jobs/executors/commands. Invocations like the following will no longer be accepted:
jobs:
my-job:
machine: true
steps:
- run: echo hello
workflows:
my-workflow:
jobs:
- my-job:
unknown_arg: "hi" # this will error, unknown_arg is not a formal parameter for my-job
An error will be reported instead:
Error calling workflow: 'my-workflow'
Error calling job: 'my-job'
Unexpected argument(s): unknown_arg
The reason we disallow this is because it can hide other errors, for example where a block of YAML has been indented incorrectly.