-
Notifications
You must be signed in to change notification settings - Fork 106
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
version number was not valid: Expected version '0.0.79+gdead53c+1525773154' to match version format #101
Comments
@kalfa : I just noticed this same issue with a path where we have two versioned resources. One of them was throwing the same error, and the other wasn't. My error looked like
Since the other resource was working fine, I took a look at the filenames and noticed that the one which is erroring out was the only one which had a filename with a I'm not saying this isn't also a bug; I think it is. But trying the same workaround I used might help the concourse team to understand it better also |
@HartS thanks, good hint. If true, gives a workaround. |
I haven't checked the source code, but supposedly the version needs to be semver compliant, which neither of the examples y'all posted were. (except your original version |
@eedwards-sk, that's a good reason. So "match version format" means the extracted version doesn't respect the semver syntax. In this case the error message could be more precise and show for example what's the syntax.
I thought it meant the version format I provided in the resource definition, rather the internal version syntax |
I had the same issue. Turns out I had a special character in name of the file |
This just popped up in my notifications and I found the relevant clauses in the semver spec: https://semver.org/#spec-item-9 and https://semver.org/#spec-item-10
So basically, all characters after the major.minor.patch numbers should match |
I use some S3 buckets, two examples in the image.
In the task creating the Pipfile I added a further information in one of the s3 stored data's version, which is the timestamp.
So it changed from Pipfile-0.0.79+gdead53c.lock to Pipfile-0.0.79+gdead53c+1525773154.lock
The first filename matchs the regexp and everything worked nice.
The second raises the error attached.
I would think that Pipfile-(.*).lock would match both, but it doesn't.
The build-package artefact which does not contain the timestamp still works.
The text was updated successfully, but these errors were encountered: