You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Dirty versions cause errors where version strings are expected to be orderable according to SLS spec.
Caused by: com.palantir.logsafe.exceptions.SafeIllegalArgumentException: Not an orderable version: {value}: {value=1.203.1-8-ge437d05.dirty}
at com.palantir.logsafe.Preconditions.checkArgument(Preconditions.java:64)
at com.palantir.sls.versions.OrderableSlsVersion.valueOf(OrderableSlsVersion.java:48)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
...
I think it a sensible outcome that when an orderable version is required, .dirty is rejected because they are not orderable. We specifically made sls-packaging lenient to avoid this problem. Pasted from the sls-spec:
Non-orderable version strings
Version strings follow the non-orderable format if they match the follow regular expression:
^[0-9]+.[0-9]+.[0-9]+(-[a-z0-9-]+)?(.dirty)?$
For example, 1.0.0.dirty, 0.0.1-custom-description-42, and 2.0.0-1-gaaaaaa.dirty are valid but non-orderable version strings, whereas 5.0, 1.1.2.3-foo, 1.1.2.3 and 1.0.0-FOO are not valid version strings under this spec.
There are no ordering guarantees for a pair of non-orderable versions, or between an orderable and a non-orderable version string.
What happened?
Dirty versions cause errors where version strings are expected to be orderable according to SLS spec.
Validation is failing in OrderableSlsVersion.java.
What did you want to happen?
Unsure.
.dirty
bit.gitOrderableVersion()
which returns the version without.dirty
.The text was updated successfully, but these errors were encountered: