Check fails for s3 buckets containing files with spaces in their names #138
Description
I have the following resource:
- name: functional-tests-screenshots
type: s3
source:
bucket: ((bucket_name))
regexp: screenshots/(.*).png
region_name: eu-west-2
I have the following two files in my s3 bucket
screenshots/2019-11-08-17-02-18 test_edit_and_delete_email_template.png
screenshots/2019-11-08-17-02-18_test_edit_and_delete_email_template.png
Checks fail with the following error message:
resource script '/opt/resource/check []' failed: exit status 2
stderr:
panic: version number was not valid: Expected version '2019-11-08-17-02-18 test_edit_and_delete_email_template' to match version format
goroutine 1 [running]:
github.com/concourse/s3-resource/versions.Extract(0xc0000a6140, 0x47, 0xc000086cc0, 0x14, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
/go/src/github.com/concourse/s3-resource/versions/versions.go:57 +0x30c
github.com/concourse/s3-resource/versions.GetBucketFileVersions(0x9744e0, 0xc00000c5c0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc000086ca0, 0x17, ...)
/go/src/github.com/concourse/s3-resource/versions/versions.go:145 +0x257
github.com/concourse/s3-resource/check.(*Command).checkByRegex(0xc000183e50, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc000086ca0, 0x17, 0xc000086cc0, ...)
/go/src/github.com/concourse/s3-resource/check/command.go:33 +0x7c
github.com/concourse/s3-resource/check.(*Command).Run(0xc000183e50, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc000086ca0, 0x17, 0xc000086cc0, ...)
/go/src/github.com/concourse/s3-resource/check/command.go:26 +0xce
main.main()
/go/src/github.com/concourse/s3-resource/cmd/check/main.go:32 +0x1ac
If I manually delete the file with the space in the name then checks pass again.
Note, the putting of the two files was done using the s3 resource so it is just the check which fails when there is a space in the name.
Small caveat
I am actually using a fork of the s3 resource rather than the resource itself - https://github.com/alphagov/paas-s3-resource - however the check script appears to match between the two repositories so I believe this issue still stands in upstream too.