Versions are sorted inversely

[Daniel Watkins]

I've just configured this resource against a test deb, and the versions are reported out in this order from check:

[
  {
    "number": "1:1.1.1"
  },
  {
    "number": "1:1.0"
  },
  {
    "number": "1.3"
  },
  {
    "number": "1.2"
  },
  {
    "number": "1.2~rc"
  },
  {
    "number": "1.1"
  },
  {
    "number": "1.1~rc"
  }
]

This sorting is correct, but is the inverse of the order that Concourse expects, so 1.1~rc is treated as the most recent version in pipelines.

[Mark Mercado]

From the resource type documentation:

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.

So, isn't what we're looking at correct -- it's newest (highest version) to oldest (lowest version), top-to-bottom.

[Daniel Watkins]

It doesn't appear to be. The get in my test pipeline selects the oldest version:

And they are listed in the opposite order to what we want in the UI:

[Daniel Watkins]

I'm looking at fixing this now.

[Daniel Watkins]

(If you're wondering why you haven't hit this, I've realised that this bug only appears on the initial check: every subsequent check only returns the latest version, which the code as currently written returns correctly.)