Create new release first as a draft, publish when packages uploaded

[Croydon]

Right now we have dead download links for ca. 20 - 40 minutes after every merge into master. This is because our CI first creates a new GitHub release and instantly publish it.

However, the building process for Windows and Linux is taking much longer than this and it takes time till these packages are successfully uploaded.

The CI should first create the release as a draft and only publish it when the packages are sucessfully uploaded.

Switching to a release draft should be a small change in the API call and publishing it can be done with an additional Travis job as an additional Travis build stage.

We need to make sure that both Travis AND AppVeyor are finished before publishing.

[Fohlen]

This also includes

• [ ] compiling a version of the ui-interfaces and uploading the dist folders to GitHub. Because currently, they won't work..

[Croydon]

Are we doing in ui-interfaces stuff in a different way than in the other ui interfaces or do we need to build them for all ui interfaces at some point?

Not sure though if this should be an extra issue though..

[Fohlen]

@Croydon we need to build them for all ui interfaces at some point before the release. I don't think we need a separate ticket. This is a friggin simple task, that either we or the CI should do.. Just don't forget it before release, or the user's don't have interfaces 🤣

[Croydon]

Then please create an extra issue, because I wouldn't give attention to this one before the v0.9 release since it's not absolutely necessary.

[Croydon]

Update: We need to make sure that both Travis AND AppVeyor are finished before publishing.

[a-teammate]

okay, well the real problem is that some dead download links are pointing to the inexor-core releases and not checking whether the assets are there.

my problem with creating a draft is: thats not continuous deployment anymore. and if you want to make it continuous again, its a lot of extra work probably.

in inexor-flex we do not have dead download links as we check whether the release contains assets already. if the website contains dead links, maybe the links should be checked before updating? or some other solution :)

[Croydon]

When you publish a GitHub release draft then it's not any longer a draft.

[a-teammate]

Right, but you need to do it manually its not done automatically anymore

[Croydon]

No, just automatically edit the release when everything is uploaded.

https://developer.github.com/v3/repos/releases/#edit-a-release

[a-teammate]

how do you check whether everything is uploaded? is there a hook?

[a-teammate]

Any ideas how this could be done in a non-ugly way?

I dont really see it, besides writing a script for travis as well as appveyor to check whether it is the first one to upload its packages and also writing a script for both travis and appveyor to afterwards modify the release.

Maybe the same script could be used? i.e. by writing it not in bash/batch, but a crossplatform scripting language?

I see that it is not nice to have for half an hour a release on the github page which does not have a correct description and all attachments.

[Croydon]

I believe that any future download should first check for each release if the expected download file actually exists, if not, treat the release as it wouldn't exist.

Releases can be always corrupt, so this should be done no matter what we are doing beyond that.

For the sake of this issue I guess most solutions are too complicated for what we would gain, as it is mostly cosmetic when downloaders can handle such scenarios.