New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: failing to set the appveyor version should not be a fatal build error #1263

Merged
merged 4 commits into from Feb 4, 2017

Conversation

Projects
None yet
2 participants
@ghuntley
Copy link
Member

ghuntley commented Feb 4, 2017

Do you want to request a feature or report a bug?

chore/bug

What is the current behaviour?

When a build starts, the initial identifier is an auto-incremented value supplied by AppVeyor. As part of the build script, this version in AppVeyor is changed to be the version obtained from GitVersion. This identifier is purely cosmetic and is used by the core team to correlate a build with the pull-request.

In some circumstances, such as restarting a failed/cancelled build the identifier in AppVeyor will be already updated and default behaviour is to throw an exception/cancel the build when in fact it is safe to swallow or append additional metadata (like the epoch when the build was started)

What is the expected behavior?

This throwing should not be a fatal build error https://github.com/reactiveui/ReactiveUI/blob/develop/build.cake#L289.

Which versions of ReactiveUI, and which platform / OS are affected by this issue? Did this work in previous versions of ReativeUI? Please also test with the latest stable and snapshot (http://docs.reactiveui.net/en/contributing/snapshot/index.html) versions.

v7.1.0

Other information (e.g. stacktraces, related issues, suggestions how to fix)

This is the root cause of the build problems experienced at #1252 - once this has been merged, update that PR via the update branch button and it will work again.

@ghuntley ghuntley added this to the vNext milestone Feb 4, 2017

@coveralls

This comment has been minimized.

Copy link

coveralls commented Feb 4, 2017

Coverage Status

Coverage remained the same at 65.574% when pulling 01760e9 on issue-1262 into b770d75 on develop.

@ghuntley ghuntley merged commit 817dcce into develop Feb 4, 2017

3 checks passed

continuous-integration/appveyor/branch AppVeyor build succeeded
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
coverage/coveralls Coverage remained the same at 65.574%
Details

@ghuntley ghuntley deleted the issue-1262 branch Feb 4, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment