FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Coverage & CI Setup Improvement by vmuriart · Pull Request #335 · pythonnet/pythonnet · GitHub

Coverage & CI Setup Improvement - #335

Closed
vmuriart wants to merge 4 commits into
pythonnet:masterfrom
vmuriart:ci
Closed

Coverage & CI Setup Improvement#335
vmuriart wants to merge 4 commits into
pythonnet:masterfrom
vmuriart:ci

Conversation

vmuriart commented Jan 27, 2017
edited
Loading

Copy link
Copy Markdown
Contributor

What does this implement/fix? Explain your changes.

  • Add coverage (cs code limited to windows, no mature coverage tools for mono)
  • Cleans up CI configurations
  • Speeds up Travis ~30% by using containers
  • Simplifies and unfreezes mono setup
  • Speed up AppVeyor by 50% by not downloading and building with miniconda.

Does this close any currently open issues?

#237
#334

Any other comments?

Sample coverage report.

Checklist

Check all those that are applicable and complete.

vmuriart self-assigned this Jan 27, 2017

codecov-io commented Jan 27, 2017
edited
Loading

Copy link
Copy Markdown

Codecov Report

❗ No coverage uploaded for pull request base (master@ef133a3).

@@           Coverage Diff            @@
##             master    #335   +/-   ##
========================================
  Coverage          ?   61.1%           
========================================
  Files             ?      61           
  Lines             ?    5324           
  Branches          ?     897           
========================================
  Hits              ?    3253           
  Misses            ?    1832           
  Partials          ?     239

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ef133a3...44ba698. Read the comment docs.

Comment thread .travis.yml
- sudo DEBIAN_FRONTEND=noninteractive apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confnew" install mono-devel mono-complete referenceassemblies-pcl ca-certificates-mono nunit-console
env:
global:
- LD_PRELOAD=/lib/x86_64-linux-gnu/libSegFault.so

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

can you explain the purpose of this?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

It can help get a bit more info on the tracebacks:
http://stackoverflow.com/a/18947029/5208670

Copy link
Copy Markdown
Contributor

@vmuriart this pull request removes the conda packages. Is there any reason for this?

Copy link
Copy Markdown
Contributor

@vmuriart can we break this into 2 PR? one for code coverage and one for build improvements?

Copy link
Copy Markdown
Contributor Author

The conda packaging is what makes the builds the AppVeyor extremely slow and we don't even use them for testing. Do we need them as part of the CI?

den-run-ai commented Jan 29, 2017
edited
Loading

Copy link
Copy Markdown
Contributor

@vmuriart we build conda packages, and provide the recipe and downloadable binaries (from appveyor artifacts) for everyone to use in this project. @filmor was very happy about conda support. we do not test conda package, but could add couple lines in appveyor.yml to do this.

Regarding the low speed of the builds - we can re-use installed Miniconda environments from appveyor CI.

It is also important to show how the conda recipe is used to build the package, since this is not trivial.

Finally I plan to extend this conda recipe to conda-forge.

Copy link
Copy Markdown
Contributor Author

I tried using the built in miniconda's, they were incomplete (don't have the build command 😞.

I thought the interest on the original pr was to create the recipe for miniconda (which is still with the package). @filmor can clarify a bit more on this.

If the intent though really is for AppVeyor to build the miniconda packages, we can have them build only on pr or when the build was triggered by a schedule (ie, they would be built once a day)

den-run-ai commented Jan 29, 2017 via email

Copy link
Copy Markdown
Contributor

vmuriart commented Jan 29, 2017
edited
Loading

Copy link
Copy Markdown
Contributor Author

Long-term, moving this to conda-forge is probably the better way. For now I rewrote the pull request to keep conda-build part of the CI, but only build them if its part of a Pull Request.

On my fork they weren't building, but it did once it was uploaded to this pull request.
It makes more sense to build on pull requests than on a scheduled basis, since the scheduled one will probably keep rebuilding the same unchanged branch.

Copy link
Copy Markdown
Contributor Author

whoops, deleted the wrong branch earlier. sorry

filmor left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

In general, I think we should have most if not all testing integrated into the conda build recipe. That could simplify the travis and appveyor configuration quite a bit

Comment thread appveyor.yml
- PYTHON_VERSION: 3.3
- PYTHON_VERSION: 3.4
- PYTHON_VERSION: 3.5
- PYTHON_VERSION: 3.6

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Are you sure about this? Wouldn't this result in the version numbers being parsed as floats?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

They are still being used as strings. Remeber this is doing set PYTHON_VERSION=3.3 which comes out as a string when you do %PYTHON_VERSION%

Comment thread appveyor.yml
- set PYTHON=C:\PYTHON%PYTHON_VERSION:.=%
- if %PLATFORM%==x86 (set CONDA_BLD_ARCH=32)
- if %PLATFORM%==x86 (set NUNIT=%NUNIT%-x86)
- if %PLATFORM%==x64 (set PYTHON=%PYTHON%-x64)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Why don't you use %CONDA_PY%? Why change the casing?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

%CONDA_PY% was removed originally, I added it back later, but decided to keep it on PYTHON_VERSION in case it was removed later.
The casing was to keep all constants on upper case and the rest on lowercase.

Comment thread appveyor.yml
# Shortcut path to executables. Mostly because of OpenCover
- set PYTHON_EXE=%PYTHON%\python.exe
- set NUNIT_EXE=.\packages\NUnit.Runners.2.6.2\tools\%NUNIT%.exe
- set OPENCOVER_EXE=.\packages\OpenCover.4.6.519\tools\OpenCover.Console.exe

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

You are hard-coding versions here, this just leads to unnecessary pain (e.g. I'd like to update NUnit in the future).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Its a very annoying shortcoming from OpenCover.

Comment thread appveyor.yml Outdated
test_script:
- ps: '& "$env:PYTHON\\Scripts\\pip.exe" install --no-cache-dir --force-reinstall --ignore-installed ("dist\\" + (gci dist\*.whl)[0].Name)'
- ps: copy-item (gci -path build -re -include Python.Test.dll)[0].FullName C:\testdir
- "%PYTHON%\\python.exe src\\tests\\runtests.py"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Is this still carried out somewhere?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

yes. here

Copy link
Copy Markdown
Contributor Author

@filmor My problem with that is that the conda build adds an extra 60-90 seconds per build and then it wouldnt be testing under our standard packing that we would use on pypi. If you unpack the wheel and the conda recipe output, they are nearly the same so double testing/building is redundant with the exception that conda build puts alot of it out of our hands.

Originally I wanted to remove the conda build altogether from the CI testing which simplifies this alot more, but was talked into leaving it and made it so that it builds once a pull_request has been submitted.

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants


Back | FazBrowse Home | New Git URL