Electron-builder: Error: Release must be a draft

Created on 20 Apr 2016  Â·  17Comments  Â·  Source: electron-userland/electron-builder

Hey there,

I'm testing out deployments for my application. The first deployment works, but subsequent deployments all fail with Error: Release must be a draft.

For both of these builds, all I did was push a tag. I am not creating any release drafts myself, I am letting electron-builder take care of that. This process works for the first build, but fails after that. If I delete all existing releases, it works again for a single build.

Thanks!

deployment feature question readme improvement

Most helpful comment

Btw, once I have everything working, I'd like to contribute to the docs and help clarify the places where I had problems. I'll open another issue to discuss the changes I plan to make before I open a PR.

All 17 comments

Github release is a tag. If you push tag — it means that if you need to do additional changes later, you have to remove tag and tag new commit again. And... it is not good to change tag.

So, don't create tags — when you will release, tag will be created by GitHub automatically.

Well, may be we can transform tag into GitHub Release (it makes sense — you push tag and electron-builder should just upload artifacts to this tag).

Please confirm – is there reason to make tag by hand or it is ok for you if GitHub will create tags for you.

My usual workflow on other projects is to tag my commits locally and push those tags to GitHub, then draft and publish my releases. I can change this workflow if needed.

When creating a draft release on GitHub, it doesn't seem to make a tag until the draft is published. This means that my Appveyor and Travis CI builds won't start until I publish the release, at which point electron-builder won't upload artifacts, because the release is published and not a draft.

I think there's something basic about the intended release workflow that I'm missing here.

my Appveyor and Travis CI builds won't start until I publish the release, at which point electron-builder won't upload artifacts

See https://github.com/electron-userland/electron-builder/wiki/Publishing-Artifacts — "If CI server detected, — onTagOrDraft."

Appveyor/Travis CI by default run on every push. So,

What does it means? Draft a new release (version (v1.0) must be equals to version (1.0) in the application package.json) and each CI build will update artifacts. It allows you to get latest artifacts in any time and publish release once it is ready.

Do you understand? — "publish release once it is ready".

usual workflow on other projects is to tag my commits locally and push those tags to GitHub, then draft and publish my releases

And what to do if build failed? Or after test you found that release is not good? So, I suggest you — just draft release, run CI on each push (artifacts will be uploaded) and release is good — publish (at this moment git tag will be created automatically).

Ah okay, I understand the intended workflow now.

I have created a draft release named "v1.0.1" with a target tag name of "v1.0.1" (I've not made this tag yet). The value of version in my package.json is also 1.0.1. I then made another commit to trigger Appveyor and Travis CI builds. They printed the CI detected, so artifacts will be published if draft release exists message, but did not upload artifacts to the draft release.

Apologies if I'm overlooking something basic. I really appreciate you taking the time to walk me through this.

Btw, once I have everything working, I'd like to contribute to the docs and help clarify the places where I had problems. I'll open another issue to discuss the changes I plan to make before I open a PR.

@Lange Release name should be just "1.0.1", without "v" prefix.

Hm, I'm still having troubles. Just to be absolutely sure, what should the tag name and release name be?

I've tried setting both to every combination of v1.0.1 and 1.0.1, but nothing seems to be working.

@Lange Example: https://github.com/develar/onshape-desktop-shell/releases

tag name: v0.4.4
release name: v0.4.4

I will take a look on your logs in the evening.

update: fix tag name.

I've discovered the problem. I wasn't updating the version field of my app/package.json. I was only updating the main package.json. This resulted in my CI logs printing 1.0.1, but the artifacts were built as 1.0.0 and being deployed to that release. This also explains the Error: Release must be a draft I was getting; it was attempting to upload artifacts to my already-published v1.0.0 release, rather than drafting a new release for the v1.0.1 tag. This seems like an easy mistake to make, so perhaps electron-builder should throw an error in this case.

Also, the tag name did indeed need to be prefixed with v. This was the configuration that worked once I fixed my app/package.json:

  • Tag version: v1.0.1
  • Release title: v1.0.1

This seems like an easy mistake to make, so perhaps electron-builder should throw an error in this case.

Must be check. And I think that it will be cool if electron-builder will automatically set version to latest draft release version.

the tag name did indeed need to be prefixed with v

Sorry, error was in my previous message

Hello.
The deployment part works well in my project, but there is a problem.
When the deployment is finished, I published the release. Then CI detected the new tag and build again, the build process will failed with Error: Release must be a draft because the draft have been published. Is there any way to prevent it?
Thank you!

@KochiyaOcean Don't start build for tag:

branches:
  except:
    - "/^v\\d+\\.\\d+\\.\\d+$/"

Please see https://github.com/develar/onshape-desktop-shell/blob/master/.travis.yml#L45

What electron-builder version do you use? It must be warn in the 4.x.

@develar It's 4.2.2. Here is crash message on Travis CI
image

@KochiyaOcean You set policy to onTag, right?

@develar its onTagOrDraft

@KochiyaOcean Fixed in 5.7.0

Was this page helpful?
0 / 5 - 0 ratings

Related issues

omarkilani picture omarkilani  Â·  3Comments

iklemm picture iklemm  Â·  3Comments

noahprince22 picture noahprince22  Â·  3Comments

AidanNichol picture AidanNichol  Â·  3Comments

JohnWeisz picture JohnWeisz  Â·  3Comments