Order of PRs when set every to true

[halimacc]

Hi, when set every: true in source, the PRs returned by check should be ordered from latest to oldest. Because when set version: every at get, it starts from the version after the most recently used and move forward. In current order(oldest to latest), new PRs can never be iterated to.

[jtarchie]

Order doesn't matter to Concourse. Given a list it just iterates through them one at a time with version: every.

I don't quite understand new PRs can never be iterated. Can you give an example to help recreate the issue you are seeing?

[halimacc]

Sorry but it seems the mechanism of version: every for get is not just iterating every version through, it is as described in this issue.

My problem here is while testing example pipeline of this repo with version: every and every: true, when the resource changed, from [pr1] to [pr1, pr2, pr3] (by adding 2 new prs), no new builds will be triggered.

And I tested similar case with concourse git resource, when the resource changed from [commit1] to [commit3, commit2, commit1] (by adding 2 new commits),
with version: every, 2 new builds will be triggered in order commit2, commit3;
with version: latest, 1 new builds will be triggered for commit3.

[jtarchie]

I see. Alright, I'll get a fix out for this soon.

[jtarchie]

I don't think just putting them in reverse order will solve this problem. The github api is returning the PRs in descending updated order, so it should already be doing the proposed newest to oldest.

I think we are experiencing a different issue.

[vito]

Concourse expects chronological order, so the most-recently-updated version should be last. Not sure if that's what GitHub's API does - I'd think it'd be the opposite.

[jtarchie]

Alright, let's see if aa6b97c resolves this.

[jtarchie]

Please reopen this issue if you have problems with it passed v15.