fix(GitVersion.Core, GitVersion.Schema): improve implementation of Types and JSON keywords in GitVersion.Configuration.json #3749
Conversation
|
@BinToss just wanted to let you know while you're working on this one, the schema files are generated. The way we run generate them is using the Schema project https://github.com/GitTools/GitVersion/tree/main/src/GitVersion.Schema. You can locally run it using the following commands: dotnet build build/CI.sln --configuration=Release
dotnet run/docs.dll --target=PublishDocs --forceSo changing the schema files manually is not an option |
|
@BinToss please run |
BinToss
changed the title
pattern and other JSON keywords in GitVersion.Configuration.json
BinToss
changed the title
pattern and other JSON keywords in GitVersion.Configuration.json
The first command runs successfully. But I was able to generate some schemas by running GitVersion.Schema directly via
This runs with warnings, but completes successfully. All the warnings are caused by the tests targeting .NETFramework instead of |
src/GitVersion.Core/Core/Attributes/JsonPropertyPatternAttribute.cs
Outdated
Show resolved
Hide resolved
|
JsonScherma.Net.Generation 3.5.0 will implement a classes to support the EDIT: Oh, it was published three days ago. |
|
What are the arguments for/against assigning default values to constants in GitVersion.Configuration.ConfigurationConstants? What about also assigning those constants to their corresponding properties in the Configuration classes under GitVersion.Configuration? e.g. the preexisting Additionally, if a default in GitFlow and GitHubFlow is the same, should it be moved to If everything goes smoothly, I should have this PR ready by Thursday. |
If this is undesired, I'll remove 4746dba
This set of changes has not yet been committed. Now...how should I backport these fixes/features to 5.12? |
|
Once we get these changes merged into main, I will manually port them to 5.x, but only to generate the schema and then I will include the schema for 5.x in the main branch |
|
I managed to get build.ps1 working properly. Which is nice. Now I can see that adding the JsonPropertyDefaultAttribute and related classes had no effect on the schemas despite calling DefaultIntent. I'll try to figure that out and a few schema validation false-positives over the weekend. |
|
@BinToss please rebase your changes on |
|
Rebase done. During the weekend, I didn't have as much time to look into the aforementioned issues as I'd hoped. I should have an opening tomorrow night to investigate. |
|
Do the tests need to be updated or is there something wrong with my changes? Some of these assert exceptions shouldn't have been caused by my changes.
|
|
I hadn't known I needed to add more calls to AttributeHandler.AddHandler at We're re-implementing attributes and handlers already provided under namespace |
|
I don't remember exactly why I had to add those attributes but I suspect that that was the case. We try to remove any dependency from the GitVersion.Core. But taking in consideration we recently moved the configuration code to its own project I guess you can try to use the JsonSchema.Net.Generation version, and add a dependency on that package to the GitVersion.Configuration project |
|
Also, the "nullableOfDateTimeOffset": {
"format": "date-time",
"description": "Commits before this date will be ignored. Format: yyyy-MM-ddTHH:mm:ss.",
"type": [
"object",
"null"
],
"properties": {
"date": {
"$ref": "#/$defs/dateTime"
},
"date-time": {
"$ref": "#/$defs/dateTime"
},
"day": {
"$ref": "#/$defs/integer"
},
"day-of-week": {
"enum": [
"Sunday",
"Monday",
"Tuesday",
"Wednesday",
"Thursday",
"Friday",
"Saturday"
],
"readOnly": true
},
"day-of-year": {
"$ref": "#/$defs/integer"
},
"hour": {
"$ref": "#/$defs/integer"
},
"local-date-time": {
"$ref": "#/$defs/dateTime"
},
"microsecond": {
"$ref": "#/$defs/integer"
},
"millisecond": {
"$ref": "#/$defs/integer"
},
"minute": {
"$ref": "#/$defs/integer"
},
"month": {
"$ref": "#/$defs/integer"
},
"nanosecond": {
"$ref": "#/$defs/integer"
},
"offset": {
"$ref": "#/$defs/timeSpan"
},
"second": {
"$ref": "#/$defs/integer"
},
"ticks": {
"$ref": "#/$defs/integer1"
},
"time-of-day": {
"$ref": "#/$defs/timeSpan"
},
"total-offset-minutes": {
"$ref": "#/$defs/integer"
},
"utc-date-time": {
"$ref": "#/$defs/dateTime"
},
"utc-ticks": {
"$ref": "#/$defs/integer1"
},
"year": {
"$ref": "#/$defs/integer"
}
}
},i.e. a nullable object with properties instead of a nullable string. I'm tempted to EDIT: the deed is done |
|
Tests failing locally:
|
…lt` annotation in schemas Only constant values can be passed to attributes, but an attribute's constructor can convert a parameter to the desired Type.
…o 'JsonPropertyDefault'
…n from `pattern` They are not mutually-inclusive. They have different purposes and can be used without the other.
also, update property descriptions and add comments
…for CommitDateFormat
…operty attributes
…faultLabelNumberPattern And fix pattern inconsistency. It was failing tests.
Switches should not have values and some keys' values should not be enclosed with double-quotes. Both were leading to fatal errors.
…nd recommend running build.ps1 with "build,BuildPrepare"
…zing Nullable<DateTimeOffset> Nullable types seem to ignore the types' built-in JSON converters i.e. DateTimeOffset <=> string, but DateTimeOffset? <=> object or null
|
GitHub check Edit: I needed to regenerate the schema, anyway. Maybe this exception was a transient issue. |
|
@arturcic All checks are passing |
|
@BinToss I will hopefully have a look today |
|
Thank you @BinToss for your contribution! |
|
@arturcic The 5.12 schemas in main never received the fixes. |
|
that is because the schema generation from code was implemented in v6, that hopefully soon we can have GA release. I tried to generate the 5.12 version long time ago, but that is a challenging think to do as 5.x is not maintained anymore, so I'd say you can start using v6 version and the latest beta from 6.x series |
Description
Related Issue
Closes #3739
Motivation and Context
While editing a GitVerison.yml in one of my projects, VSCode's redhat.vscode-yaml extension highlighted the values of some fields as errors, stating that the values (regex patterns) was invalidated by the regex pattern required by the schema (GitVersion.configuration
How Has This Been Tested?
# yaml-language-server: $schema=../schemas/6.0/generatedschema.jsonScreenshots (if appropriate):
Checklist: