Add appveyor configuration for windows proof builds #2839

Merged
merged 1 commit into from Feb 12, 2017

Projects

None yet

2 participants

@hacst
Member
hacst commented Feb 12, 2017

The current configuration uses a hacked up
win64-static-no-ltcg build environment until we
build our next set of real ones. As we do not want
to distribute our build env at this point the source
is obfuscated for now.

We utilize the appveyor cache to cache the compressed
build environment we downloaded. We do not cache the
uncompressed variant to save the time it takes to package
it up in case of cache invalidation. Cache invalidation
is keyed on changes to the appveyor.yml .

@hacst hacst requested a review from mkrautz Feb 12, 2017
appveyor-build.ps1
@@ -0,0 +1,33 @@
+#
@mkrautz
mkrautz Feb 12, 2017 edited Member

We should probably move this to scripts/appveyor/appveyor-build.ps1?

appveyor-install-environment.ps1
@@ -0,0 +1,38 @@
+#
@mkrautz
mkrautz Feb 12, 2017 edited Member

We should probably move this to scripts/appveyor/appveyor-install-environment.ps1?

+
+environment:
+ MUMBLE_BUILDSCRIPT: 1.3.x/mumble-win64-static.cmd
+ MUMBLE_ENVIRONMENT_VERSION: win64-static-no-ltcg-1.3.x-2017-02-02-ec94ddb-790
@mkrautz
mkrautz Feb 12, 2017 Member

Hmmm. I would have liked we would just use the latest available buildenv. But I guess that one is on me. :-)

@hacst
hacst Feb 12, 2017 edited Member

That requires a different cache invalidation strategy. We could download a marker file in the init stage that we can use for invalidation I think. Also not having build env version checked in will mean any patch will always build with the newest one instead of the one current for the branch. Maybe we want that but it makes hard to know whether a CI result is still valid. It definitely prevents the builds there from being reproducible (for us or the user).

An alternative suggestion would be to have something like transifexbot for new environment versions. What would be neat about that is that the appveyor would automatically test building mumble with the changed environment before we can ever merge it. If we make that a file seperate from appveyor.yml that we pick up in our own build system too that might be a basis for reproducible windows builds. Not sure how valuable that is in practice.

@mkrautz
mkrautz Feb 12, 2017 Member

The build itself isn't tied to the buildenv version in the 'real world' either.

I'd like to have it update automatically, but I like the simplicity of using hash(appveyor.yml) for cache invalidation...

OK for now. :)

appveyor.yml
@@ -0,0 +1,22 @@
+version: 1.3.{build}-{branch}
@mkrautz
mkrautz Feb 12, 2017 Member

At the very least, 1.3.0-{build}-{branch}

@mkrautz
mkrautz Feb 12, 2017 Member

Or maybe 1.3.x-{build}-{branch}?

@hacst
hacst Feb 12, 2017 Member

How about 1.3.x-proofbuild-{build}? That version is only displayed on appveyor and branch shows "master" for PRs against master so it'll be pretty useless information in any situation I can think about.

@hacst hacst Add appveyor configuration for windows proof builds
The current configuration uses a hacked up
win64-static-no-ltcg build environment until we
build our next set of real ones. As we do not want
to distribute our build env at this point the source
is obfuscated for now.

We utilize the appveyor cache to cache the compressed
build environment we downloaded. We do not cache the
uncompressed variant to save the time it takes to package
it up in case of cache invalidation. Cache invalidation
is keyed on changes to the appveyor.yml .
86f8eef
@hacst
Member
hacst commented Feb 12, 2017

@mkrautz PTAL

+image: Visual Studio 2015
+
+cache:
+ - C:\MumbleBuild\cache -> appveyor.yml
@mkrautz
mkrautz Feb 12, 2017 Member

Is this the cache invalidation strategy?

@mkrautz mkrautz merged commit 7bd6b6c into master Feb 12, 2017

2 checks passed

continuous-integration/appveyor/branch AppVeyor build succeeded
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
@hacst hacst deleted the appveyor branch Feb 12, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment