Skip to content

Add automated windows CI using appveyor#2836

Closed
mwcraig wants to merge 17 commits into
astropy:masterfrom
mwcraig:try-appveyor
Closed

Add automated windows CI using appveyor#2836
mwcraig wants to merge 17 commits into
astropy:masterfrom
mwcraig:try-appveyor

Conversation

@mwcraig

@mwcraig mwcraig commented Aug 8, 2014

Copy link
Copy Markdown
Member

This PR adds automatic testing on windows using appveyor.com.

It is based on, and incorporates parts of, https://github.com/rmcgibbo/python-appveyor-conda-example by @rmcgibbo, which is in turn a fork of https://github.com/ogrisel/python-appveyor-demo by @ogrisel. Honestly, they did all of the hard work!

To see an example of the report produced, go to: https://ci.appveyor.com/project/mwcraig/astropy/build/1.0.8

It does not test the same range of python/numpy variants as the travis tests, but does cover the basics: python 2.7 and 3.4 on both 32 and 64 bit.

I took a quick look at the failures in 64-bit...they look like real test failures rather than problems with the appveyor configuration.

Before this is merged we would need to:

  • setup up an astropy account on appveyor (free for open source projects)
  • link the astropy repo to the appveyor account (done from appveyor, not github)

I hope to soon make a couple of additional pull request mining the goodness in the appveyor examples to automatically build conda packages of the dev version of astropy (for travis) and for affiliated packages (for linux and windows)....but this was the most straightforward place to start.

@astrofrog

Copy link
Copy Markdown
Member

Thanks! It looks like you had the same idea as @Cadair: #2755 - maybe you guys could try and see how different the solutions are and which one to go with?

I have created an astropy account on appveyor, will send it to the two of you later. Do you both have PGP set up?

@astrofrog

Copy link
Copy Markdown
Member

I have added the astropy, astropy-helpers, and package-template repositories to the appveyor astropy account.

@astrofrog

Copy link
Copy Markdown
Member

If we go ahead with this solution, can we make the continuous-integration folder invisible?

It looks like this includes both 32- and 64-bit builds. @Cadair, does yours include that too? What are the main differences between the two solutions?

@Cadair

Cadair commented Aug 8, 2014

Copy link
Copy Markdown
Member

I can add 32bit builds with one extra line in the config file. I spent some time on mine getting rid of some of the setup code that isn't needed when using miniconda, which still seems to be in this version.

@Cadair

Cadair commented Aug 8, 2014

Copy link
Copy Markdown
Member

This version also does a little more in the powershell install script, where as #2755 does mostly everything in the appveyor.yml config file, apart from the install of miniconda. I prefer it that way because it keeps the need to edit the powershell to a minimum (as it is evil).
My install script sets a few extra install flags for miniconda, which are probably superfluous.

Otherwise I don't think there is a lot of difference, they are both based on the same code.

@Cadair

Cadair commented Aug 8, 2014

Copy link
Copy Markdown
Member

Mine also has the miniconda version set from the appveyor.yml file as well, this one downloads miniconda3 for a Python 3 build, where as I set it up in the env from a miniconda2 installer..

It seems that @mwcraig's handle on powershell is better than mine so he did more stuff in the powershell where as I did as much as I could get away with in the yml.

@mwcraig

mwcraig commented Aug 8, 2014

Copy link
Copy Markdown
Member Author

😊 Can't believe I didn't check the list of open issues first...

In any event, this version compiles on 64-bit -- the 64-bit fails here are real test fails, but I think I know which piece in mine would fix @Cadair's.

To keep things simpler, I'll close this PR and make a few PRs on @Cadair's fork instead.

There will be at least two files beyond appveyor.yml added: install.ps1 and run_with_environment.cmd, so I'd propose putting them in a subfolder. I'll formalize that in a PR on @Cadair later today.

Just to be clear I don't know much of anything about powershell, but I'm really good at copy and paste and happened upon a more recent variant of this than you had :)

@mwcraig mwcraig closed this Aug 8, 2014
@Cadair

Cadair commented Aug 8, 2014

Copy link
Copy Markdown
Member

@mwcraig as far as I can tell we don't need run_with_environment.cmd because of miniconda having mingw as a package. I have already added a .install_miniconda.ps1 file, so there is two in total in my branch.

@mwcraig

mwcraig commented Aug 8, 2014

Copy link
Copy Markdown
Member Author

@Cadair -- I think we do actually need it. The difference between two 64-bit builds I tried is below.

The first, which did not set the environment variables, failed at compile (https://ci.appveyor.com/project/mwcraig/astropy/build/1.0.4#L915)

The second, which set the environment variables, succeeded in compiling, though three tests failed (https://ci.appveyor.com/project/mwcraig/astropy/build/1.0.7#L2073)

My limited experience with compiling 64 bit in windows for conda is that magic is usually required, unfortunately...

diff --git a/appveyor.yml b/appveyor.yml
index 456c247..22eef85 100644
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -44,7 +44,7 @@ test_script:
   # doesn't really work.
   #
   #- "%CMD_IN_ENV% conda build conda-recipe --quiet"
-  - python setup.py test
+  - "%CMD_IN_ENV% python setup.py test"

 #artifacts:
   # Archive the generated conda package in the ci.appveyor.com build report.

embray added a commit to embray/astropy that referenced this pull request Aug 19, 2014
…onger needs to include its own copy of the make_func_with_sig utility. I also renamed make_func_with_sig to make_function_with_signature as suggested here: astropy#2835 (comment)  Previously I thought the unabbreviated name was a little on the long side.  But on second thought I prefer the clarity here.
embray added a commit to embray/astropy that referenced this pull request Aug 19, 2014
…onger needs to include its own copy of the make_func_with_sig utility. I also renamed make_func_with_sig to make_function_with_signature as suggested here: astropy#2835 (comment)  Previously I thought the unabbreviated name was a little on the long side.  But on second thought I prefer the clarity here.
embray added a commit to embray/astropy that referenced this pull request Sep 3, 2014
…onger needs to include its own copy of the make_func_with_sig utility. I also renamed make_func_with_sig to make_function_with_signature as suggested here: astropy#2835 (comment)  Previously I thought the unabbreviated name was a little on the long side.  But on second thought I prefer the clarity here.
embray added a commit to embray/astropy that referenced this pull request Sep 24, 2014
…onger needs to include its own copy of the make_func_with_sig utility. I also renamed make_func_with_sig to make_function_with_signature as suggested here: astropy#2835 (comment)  Previously I thought the unabbreviated name was a little on the long side.  But on second thought I prefer the clarity here.
embray added a commit to embray/astropy that referenced this pull request Sep 30, 2014
…onger needs to include its own copy of the make_func_with_sig utility. I also renamed make_func_with_sig to make_function_with_signature as suggested here: astropy#2835 (comment)  Previously I thought the unabbreviated name was a little on the long side.  But on second thought I prefer the clarity here.
embray added a commit to embray/astropy that referenced this pull request Oct 2, 2014
…onger needs to include its own copy of the make_func_with_sig utility. I also renamed make_func_with_sig to make_function_with_signature as suggested here: astropy#2835 (comment)  Previously I thought the unabbreviated name was a little on the long side.  But on second thought I prefer the clarity here.
embray added a commit to embray/astropy that referenced this pull request Oct 15, 2014
…onger needs to include its own copy of the make_func_with_sig utility. I also renamed make_func_with_sig to make_function_with_signature as suggested here: astropy#2835 (comment)  Previously I thought the unabbreviated name was a little on the long side.  But on second thought I prefer the clarity here.
embray added a commit to embray/astropy that referenced this pull request Oct 21, 2014
…onger needs to include its own copy of the make_func_with_sig utility. I also renamed make_func_with_sig to make_function_with_signature as suggested here: astropy#2835 (comment)  Previously I thought the unabbreviated name was a little on the long side.  But on second thought I prefer the clarity here.
embray added a commit to embray/astropy that referenced this pull request Nov 12, 2014
…onger needs to include its own copy of the make_func_with_sig utility. I also renamed make_func_with_sig to make_function_with_signature as suggested here: astropy#2835 (comment)  Previously I thought the unabbreviated name was a little on the long side.  But on second thought I prefer the clarity here.
@astrofrog

Copy link
Copy Markdown
Member

Good news everyone! Looks like GitHub now officially supports having multiple CI statuses :)

https://github.com/blog/1935-see-results-from-all-pull-request-status-checks

@Cadair

Cadair commented Dec 8, 2014

Copy link
Copy Markdown
Member

woop! woop!

@ogrisel

ogrisel commented Dec 8, 2014

Copy link
Copy Markdown

Nice!

@embray

embray commented Dec 9, 2014

Copy link
Copy Markdown
Member

I wonder why I referenced this PR in so many commits... must have been a typo. Sorry 'bout that.

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants