Check step fails when previous version doesn't exist anymore

[lunikon]

I use this resource to download files from an external FTP server of a business partner, so we do not control the content/versions ourselves. They typically only leave the latest version of the file on the server and delete any previous ones.

Due to this, the FTP resources fails with an error like this:

resource script '/opt/resource/check []' failed: exit status 1

stderr:
connecting to ftp server
logging in
changing to directory 
Traceback (most recent call last):
  File "/opt/resource/check", line 227, in <module>
    print(FTPResource().run(os.path.basename(__file__), sys.stdin.read(), sys.argv[1:]))
  File "/opt/resource/check", line 73, in run
    output = self.cmd_check(version=data.get('version', {}))
  File "/opt/resource/check", line 133, in cmd_check
    new_versions = versions[versions.index(current_version):]
ValueError: {'version': 'X.Y.Z'} is not in list

I'm no Python expert, but I assume the issue is because the current version is not in the hash anymore and hence the look-up fails.

In such a case, would it be possible to just return the latest version? Or does that go against the contract for the check script?

[aequitas]

I could probably add an option to explicitly only expect one version. Would that work?

[lunikon]

I checked the documentation real quick and it says (see https://concourse.ci/implementing-resources.html):

A resource type's check script is invoked to detect new versions of the resource. It is given the configured source and current version on stdin, and must print the array of new versions, in chronological order, to stdout, including the requested version if it's still valid.

Note the emphasized part: I would interpret this as such that the correct behavior would be to return a list of versions in any case. The requested version should only be part of the list when it is still valid, so it not being valid anymore seems to be a well-defined case.

Consequently, I don't think making this a special case (and option to only expect a single version, for example) would be the right way to go.

[lunikon]

Any news on this?

[aequitas]

Should be fixed now: #9, sorry for the delay.