test: pin job-name length limits after parameter substitution - #184
test: pin job-name length limits after parameter substitution#184wyongzhi wants to merge 1 commit into
Conversation
| @@ -0,0 +1,16 @@ | |||
| template: | |||
There was a problem hiding this comment.
Please add a description to the test what it is testing.
EG: Section x.y.z of the spec, it is invalid to have a string longer than 128 (or something like this)
There was a problem hiding this comment.
Added. Header now reads: spec 1.1.1 , max 128 characters checked after the format string is resolved; the name resolves to 129 via {{Param.N}}, so job creation must fail while the template itself decodes fine.
| parameterDefinitions: | ||
| - name: N | ||
| type: STRING | ||
| default: "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" |
There was a problem hiding this comment.
Same here, with FEATURE_BUNDLE_1, spec x.y.z, we can have a longer string 512.
There was a problem hiding this comment.
Added, same shape: spec 1.1.1 with FEATURE_BUNDLE_1, max 512 after resolution, resolves to 512 and must be accepted. Also added an expected.output assertion (the task prints the resolved length) — the runner only checks expected output for valid job tests, so without it a job-creation failure would still show as a pass. The 513 fixture got the same header.
Existing boundary fixtures use literal job names, so an implementation that checks the literal at decode but mishandles the resolved value at job creation still passes the suite. These fixtures set the job name via a bare {{Param.N}} substitution so the limit is enforced after the format string has been resolved: 129 chars with no extension is rejected, 512 chars with FEATURE_BUNDLE_1 is accepted, and 513 chars is rejected.
The valid 512-char fixture asserts the task's output (the resolved name length), because the runner only checks expected output for valid job tests; without it a job-creation failure would still be reported as a pass.
Signed-off-by: Yongzhi Wei <276409147+wyongzhi@users.noreply.github.com>
e9d8b8e to
8fea26d
Compare
|
The |
2 participants
Adds three job-execution conformance fixtures that make the job name cross a length boundary through job-parameter substitution:
{{Param.N}}resolves to2023-09/base/jobs/1.1.1--job-name-too-long-substitution.invalid.test.yaml2023-09/FEATURE_BUNDLE_1/jobs/1.1.1--job-name-512-chars-substitution.test.yaml2023-09/FEATURE_BUNDLE_1/jobs/1.1.1--job-name-513-chars-substitution.invalid.test.yamlWhy
The Template Schemas define the
JobNamelimit as "128 characters, after the format string has been resolved. 512 characters, after the format string has been resolved if using theFEATURE_BUNDLE_1extension" (§1.1.1). Every existing length-boundary fixture (1.1.1--max-length.yaml,1.1.1--too-long.invalid.test.yaml,1.1.1--job-name-512-chars.yaml,1.1.1--job-name-513-chars.invalid.yaml,1.1.1--job-name-without-extension.invalid.test.yaml) uses a literal name, and every fixture whose name is a format string resolves to 30 characters or fewer. So an implementation that applies the limits to the template literal at decode time but mishandles the resolved value at job creation passes the suite today. These fixtures lock the "after the format string has been resolved" clause for both the base and the FEATURE_BUNDLE_1 limit. The template is short and decodes fine in every case; the outcome is decided only at job creation, which is what.invalid.testis for (README: "template passes static validation but the error only fires during evaluation").The name is a bare
{{Param.N}}so the resolved length equals the parameter length exactly; the long values are written as literalAruns, as in1.1.1--job-name-512-chars.yaml. The valid 512 fixture asserts the task's output (OUTPUT:512, the resolved name length): the runner only checksexpected.outputfor valid job tests, so without it a job-creation failure would be reported as a pass. Each fixture carries a header comment naming the spec section and the limit it pins. STRING parameter defaults are capped at 1024 characters, so none of the three values can fail at decode for a parameter-value reason.Testing
run_openjd_cli_tests.pywith openjd-cli 0.7.7 against the released openjd-model-for-python 0.11.11 (no companion fix): the 512 fixture fails withMissing expected output: OUTPUT:512and the run errorString should have at most 128 characters; the two.invalid.testfixtures pass. This is the gap the fixture exists to catch..invalid.testcases reject with "at most 128 characters" and "at most 512 characters", the 512 case creates, runs, and printsOUTPUT:512.Related
Companion fix in openjd-model-for-python: OpenJobDescription/openjd-model-for-python#362 (without it, the 512 fixture fails on the Python implementation; the Rust implementation already passes all three).
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.