GitHub release deployment... how's this supposed to work?

John B.'s Avatar

John B.

23 Mar, 2015 02:18 AM

I'm not understanding the intended workflows shown in the Publishing artifacts to GitHub Releases documentation. I've played around a few times for several hours and still can't come up with a desirable solution.

  1. Both scenarios start with pushing a tag to the GitHub repo to kick off the build. But AppVeyor also creates a tag when it releases to GitHub. What tag am I supposed to use so as not to conflict with the one AppVeyor creates? Or am I supposed to match it? Am I supposed to know the next version/build number for my tag, and if so, what if someone commits right before me and changes the build number?
  2. The second scenario says 'Go to project "Deployments" tab and deploy to GitHub environment.' But there's no option there to deploy. User has to click "Update" (say what?) and then select a single (not multiple, like I want) artifact to deploy. And then, if the user is me, I get "Response status code does not indicate success: 422 (status code 422).". This might be new since I tried ticking the "drafts release" checkbox in a blind attempt to avoid...
  3. ...when I did the second usage scenario last night the deployment went right through to GitHub without waiting for me to 'promote selected "tag" build to GitHub release'. Coupled with the infinite rebuild bug, this caused a big headache overnight. The suggested solution in that thread was to configure the whole build not to build tags, but then I can't use tags (and the GitHub Releases deployment docs said to push a tag).
  4. I'm unclear on what the "GitHub Environment" in AppVeyor is. The docs seem to assume I know what an abstract, AppVeyor "environment" is. I have no idea.

Anyway, I feel like the docs need to be fleshed out. I've spent several hours attempting and I read posts in the support forum. It's just not clicking for me how this is intended to work. Could someone please help? Thanks.

  1. Support Staff 1 Posted by Feodor Fitsner on 23 Mar, 2015 04:50 AM

    Feodor Fitsner's Avatar

    Thanks for the detailed feedback!

    What would be your ideal scenario of doing GitHub releases with AppVeyor?

  2. 2 Posted by John B. on 24 Mar, 2015 04:01 AM

    John B.'s Avatar

    My product doesn't get continuously released. I post installers to GitHub. I think this might be common for folks using GitHub Releases. So here are the two options I came up with:

    1. Web UI and API: I log into AppVeyor and specify commit, title, description, draft (y/n), and prerelease (y/n), and hit "go". It tags, builds, and releases. And there's a web API to do the same thing for automation.

    2. Special branch: I designate a branch in AppVeyor to get tagged, built, and released every commit. When I want to release, I merge from master to this branch. The commit message could contain the release's title, description, draft (y/n), and prerelease (y/n) in some sensible format.

    The first option is nice because you can give the user text fields, check-boxes, and a markdown editor. They both keep a history of the commit for each release, but the second option also keeps the title/description/etc.. In the second option, the user can potentially botch the commit message syntax.

    What do you think? :)

    I tried hard to think of a way to trigger the release using tags, but I can't find a way around the aforementioned issues (have to change the tag each time, potential for duplicate tags from AppVeyor).

  3. 3 Posted by John B. on 02 Apr, 2015 03:38 AM

    John B.'s Avatar

    Any word on what you think?

    I was able to get something like #2 working, without release information via commit message since that's not supported. #1 would have been nice, too.

  4. Support Staff 4 Posted by Feodor Fitsner on 02 Apr, 2015 04:44 PM

    Feodor Fitsner's Avatar

    by #2 you mean having some special syntax for commit message to specify release title, description, etc.?

  5. 5 Posted by John B. on 02 Apr, 2015 05:37 PM

    John B.'s Avatar

    Yes, that's what I mean for #2. So, the user can trigger a whole release with a single Push. One idea that came to mind is to indicate that it's a special comment with [GitHub Release] (kind of like [skip ci] which AppVeyor already uses) then follow with XML:

    [GitHub Release]
        <title>v2.3 release</title>
        <draft />
        <prerelease />
    # New features:
    * Spell check
    * User profiles
    # Known issues
    * Auto-updater broken

    I'm not sure which is easier to implement, idea #1 or #2. But those were the ideas I came up with.

  6. Support Staff 6 Posted by Feodor Fitsner on 05 Apr, 2015 05:11 PM

    Feodor Fitsner's Avatar

    Well, sounds interesting! Please feel free to sumit a new issue for that:


  7. 7 Posted by John B. on 05 Apr, 2015 07:31 PM

    John B.'s Avatar

    Thanks, Feodor. Will do.

    Regarding the original post, my impression is that at this time:
    * The documentation needs work * The only reasonable way to deploy to GitHub is to use the "Deploy from branch" checkbox and create a special branch.

  8. 8 Posted by John B. on 05 Apr, 2015 07:44 PM

    John B.'s Avatar

    (Hm, wish I could edit that comment to fix the markdown mistake.)

  9. 9 Posted by John B. on 12 Apr, 2015 08:32 PM

    John B.'s Avatar

    Suggestions posted: #231

  10. Support Staff 10 Posted by Feodor Fitsner on 12 Apr, 2015 08:35 PM

    Feodor Fitsner's Avatar

    Looks good, thanks!

  11. Ilya Finkelshteyn closed this discussion on 25 Aug, 2018 01:55 AM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac