fix(electron-release-publisher): change api/version endpoint in PublisherERS to use versions/sorted

[kgallagher52]

• I have read the contribution documentation for this project.
• I agree to follow the code of conduct that this project follows, as appropriate.
• The changes are appropriately documented (if applicable).
• The changes have sufficient test coverage (if applicable).
• The testsuite passes successfully on my local machine (if applicable).

Summarize your changes:

Issue: #3430

Electron Release Server, specifically the Sails blueprint, only allows a maximum of 30 records to be returned on the endpoint /api/version. The problem with this is when you call:

const versions: ERSVersion[] = await (await authFetch('api/version')).json();

You get back a random 30 records. If you have 30 or more versions that have been created, this poses a problem. If you don't get the version that you are creating, say, 0.0.1_stable, on that /api/version call, it will try to create it again even though it's already been created in the database. It will result in the error:

Error: ERS publish failed with status code: 400 (*** /api/version)

If you look at the Electron Release Server error, it's giving you:

AdapterError: Would violate uniqueness constraint-- a record already exists with conflicting value(s).

Because the record has been created, but because /api/version only returns 30 records, you may not have been given that version on the call, so the check will come back that it does not exist.

Solution:

This change simply switches the GET call from /api/version to /versions/sorted, so you won't run into this issue when you have exceeded 30 versions. The endpoint I changed it to gets all versions using semvr and is documented on Electron Release Server https://github.com/ArekSredzki/electron-release-server/blob/master/docs/api.md

I also updated the type for:

const versions: ERSVersion[]

so it corresponds correctly with the return value of /versions/sorted from Electron Release Server.

Images of the errors that get thrown because of this

[BlackHole1]

Code LGTM. Can you add a some tests?

[kgallagher52]

@BlackHole1 , could I get another review? I have updated the spec to match the new endpoint. I'm also curious, once the change gets merged, does it auto-deploy so that I can use this in my project?

[BlackHole1]

LGTM

[BlackHole1]

I'm also curious, once the change gets merged, does it auto-deploy so that I can use this in my project?

Once the PR is merged, it will not be released immediately. However, we will push for this fix to be released as soon as possible.

[VerteDinde]

The fix makes sense - thanks for the thorough description and the fix!

[kgallagher52]

@BlackHole1 @VerteDinde Thank you both. Do you know what version it will be on when it gets released so I can watch for it and is there a way for me to use it in the mean time? Also do you merge this PR? I can't merge it so i'm assuming that one of you merge it?

[BlackHole1]

Do you know what version it will be on when it gets released so I can watch for it

It could be either 7.2.1 or 7.3.0, the specific version cannot be determined at the moment because we need to evaluate whether any other destructive changes or new features PRs have been merged.

is there a way for me to use it in the mean time?

Before the official release, you can use patch-package

If nothing goes wrong, we will publish within a week.