Build Windows release mode binaries, keep artifacts on any tag build

[cme]

Having tested the 32-bit release mode Windows builds, it seems that there's no longer an issue with Appveyor's 32-bit release builds immediately crashing. So enable release-mode builds for both 32-bit and 64-bit Windows so these can be used as release packages.

Also, changes the condition of whether or not to keep build artifacts from the specific branch name, to whether or not the build is started by pushing a tag. Since this only generally happens with releases or release candidates, that seems a good compromise to avoid excessive branch maintenance and chopping and changing.

[cme]

@mauser, have I misunderstood the use model for the 'build-with-artifacts' branch name as the condition for keeping artifacts? Is there an advantage to using the branch name that I've missed?

Cheers :)

[mauser]

@mauser, have I misunderstood the use model for the 'build-with-artifacts' branch name as the condition for keeping artifacts? Is there an advantage to using the branch name that I've missed?

Cheers :)

Maybe ;-) The idea was to be able to produce binaries whenever it is suitable, without the need for an "official" release. For example after a bug has been fixed (and the user who reported the issue is using Windows) or a new feature is available in the master branch.. I had the impression that creating tags just for triggering the CI process in that case is not perfect.

[cme]

Maybe ;-) The idea was to be able to produce binaries whenever it is suitable, without the need for an "official" release. For example after a bug has been fixed (and the user who reported the issue is using Windows) or a new feature is available in the master branch.. I had the impression that creating tags just for triggering the CI process in that case is not perfect.

Hmm, so the use model would be merge to that branch, or reset the branch to whatever you want to artifact?

Tagging seemed preferable to me since they are lightweight and can be moved arbitrarily between revisions, and the resultant artifacts and CI jobs have references to shas with clean and 'obvious' history. Maybe there are disadvantages i didn't think of.

But also I probably shouldn't suggest changing a mechanism if you're already using it and it works -- perhaps adding an additional one instead! :D

But the main point of this PR was: Appveyor Windows builds all seem to work now :)

[mauser]

But the main point of this PR was: Appveyor Windows builds all seem to work now :)
And that's definitely good news :) Especially that we can get rid of those unncessary cmake handling.

While implementing the branch trigger, i also thought about using a tag like 1.1-CI and move that tag when necessary. In addition, this was basically what i started with when experimenting with appveyor on my own fork of the repo. I'm not sure if moving tags around is a nice thing to do on a public repo, since you have to force push to move a tag and people who fetch the tags (which is not the default behavior of git) run into warnings and might have to delete their older, local tag. So i disregarded that solution and went on with the branch. I'm not sure about the git details here, but if i remember correctly, then those problems happen if the user uses git fetch --tags or uses a graphical git client which does the equivalent.
Building artifacts on release tags (which do not get moved) is a different thing,this makes total sense to me!
But i'm not dogmatic about this, i'm absolutely happy with every solution that gives us artifacts without having to issue a GitHub release :)

Another thing which came to my mind.. Should we enable the win32 build only for the artifacts? This would speed up the usual pull requests builds a bit. I would not expect that we find more or other errors in our specific codebase by just compiling the code also for a 32bit system.

[cme]

Hmm, looks like my previous reply here went missing or failed to post.

I'm not sure if moving tags around is a nice thing to do on a public repo, since you have to force push to move a tag and people who fetch the tags (which is not the default behavior of git) run into warnings and might have to delete their older, local tag. So i disregarded that solution and went on with the branch. I'm not sure about the git details here, but if i remember correctly, then those problems happen if the user uses git fetch --tags or uses a graphical git client which does the equivalent.

After some thought, agreed, moving tags is probably less than ideal. Perhaps builds we want to keep artifacts for are rare enough that adding a new tag for each (release candidates and actual releases) is viable? Old tags can be removed from the repo if no longer needed.

Another potential scheme is to designate a 'with artifacts' branch for each development branch that we may want to keep artifacts for. This way we could always do a clean fast-forward merge to that branch from the corresponding development branch?

[mauser]

After some thought, agreed, moving tags is probably less than ideal. Perhaps builds we want to keep artifacts for are rare enough that adding a new tag for each (release candidates and actual releases) is viable?

I suppose so, i think having tags for all "official release" (everything we write an announcement for..) will be sensible. Even if we release more often, this should not become a big problem..

Another potential scheme is to designate a 'with artifacts' branch for each development branch that we may want to keep artifacts for. This way we could always do a clean fast-forward merge to that branch from the corresponding development branch?

Agreed, that sounds like a good solution.I suppose that we rarely use more then two at the time (master and develop), since there might be no need to those releases with artifacts on the support branches (like releases/1.0).

There could be also another solution for the "non-tagged" builds. It seems that you can also trigger appveyor builds via a rest API, so maybe we could set a special parameter which we can use as a boolean condition to keep artifacts (in addition to tags). I haven't looked into this details yet, but i'm wondering why i haven't thought of that before...i'm doing sth. similiar at work with Azure DevOps :-/
But if we have only two "hard-coded" feature branches with artifacts enabled, both solutions (trigger by branch/trigger manual build via script) have no large differences (in my opinion). Triggering via script would be better if we have a larger number of branches which we don't want to put into the yaml file..