-
Notifications
You must be signed in to change notification settings - Fork 652
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] The configuration JSON schemas use the wrong properties for default values and assign bad regex patterns #3739
Comments
Good question. @arturcic, any idea what might be causing this? |
Most probably we will need to improve the description of the mentioned properties so that the generated schema is correct. |
As an aside, |
I've noticed an issue with // e.g. "555-1212" or "(888)555-1212", and NOT "(800)FLOWERS"
"type": "string",
"pattern": "^(\\([0-9]{3}\\))?[0-9]{3}-[0-9]{4}$" and // e.g. \+semver:\s?(breaking|major)
"type": "string",
"format": "regex" The former implies the value of the // e.g. "2018-11-13T20:20:39+00:00"
"type": "string",
"format": "date-time" Additionally, the I'll apply the |
I'm discussing how to use JSON's |
Why are default values–specifically, the ones identical in both GitFlow and GitHubFlow–not defined/assigned in the |
For the sake of making the PR easier on me, I'll define default values in |
🎉 This issue has been resolved in version 6.0.0-beta.4 🎉 Your GitReleaseManager bot 📦🚀 |
Describe the bug
Some properties in GitVersion.configuration.json are used for the wrong purpose (
pattern
wheredefault
should be used) or are assigned bad values (human-readable date-time formats are assigned to regex-only fields).Were these mistakes made by a schema generator?
Definitions using
pattern
when they shouldn't, assign literal strings with no regex syntax, or are annotated with the wrong type(s):pattern
regex string which must resolve to a DateTime object. This makes no sense. In the first place, this string must be usable as a parameter forSystem.Runtime.Serialization.DateTimeFormat(string formatString)
.commit-date-format
pattern
regex string is optionally used for asserting the property's value. Thedefault
annotation should be used instead.major-version-bump-message
minor-version-bump-message
no-bump-message
patch-version-bump-message
tag-number-pattern
(only in 5.12 config schema)See this branch for manual changes
RFC 3339 Max Value (no offset):
9999-12-31t23:59:59z
RFC 3339 Min Value (no offset):
0000-01-01t00:00:00z
RedHat's vscode-yaml somehow follows RFC 3339's spec. It includes case-insensitivity for the 't' and `z' (both of which are mandatory) and can process the various acceptable formats for the optional offset numbers.
Expected Behavior
The
*-version-bump-message
fields should......not use the
pattern
property expect any regex string and use thedefault
annotation field.Actual Behavior
The
*-version-bump-message
fields expect regex-like values which perfectly match the regex pattern in thepattern
field which is currently set the default values of each field.If the fields' values are different than the default values, YAML/JSON validators declare it an error.
Possible Fix
scratch that. I'm making a PR. While fixing the pattern-default issues, I discovered the regex patterns for date-time fields are useless.
GitVersion/schemas/6.0/GitVersion.configuration.json
Lines 86 to 91 in 0abd8d6
GitVersion/schemas/6.0/GitVersion.configuration.json
Lines 99 to 104 in 0abd8d6
Steps to Reproduce
In an editor with JSON/YAML validation (e.g. VSCode), create GitVersion.yml and write
minor-version-bump-message: "^(feat)(\\([\\w\\s-]*\\))?:"
to it.Context
VSCode complains that custom version bump message patterns don't match the "required" patterns for their respective fields.
Your Environment
The text was updated successfully, but these errors were encountered: