Skip to content

TST: Fix hypothesis fuzzing logic on CI - #11128

Merged
pllim merged 2 commits into
astropy:masterfrom
pllim:tst-fuzzing
Dec 4, 2020
Merged

pllim merged 2 commits into
astropy:masterfrom
pllim:tst-fuzzing

Conversation

@pllim

@pllim pllim commented Dec 3, 2020 •

Copy link
Copy Markdown
Member

Description

This pull request is to address pytest conditions in test modules that were using TRAVIS env var portion of #11038 .

Note to reviewers: Please inspect logic carefully.

Comment thread .github/workflows/ci_workflows.yml Resolved
@pllim
pllim marked this pull request as ready for review December 3, 2020 23:07
@pllim
pllim requested review from astrofrog, mhvk and saimn December 3, 2020 23:08

@saimn saimn left a comment

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.

Looks good to me, just a little comment.

Comment thread conftest.py
'fuzzing', deadline=None, print_blob=True, max_examples=1000
)
default = 'fuzzing' if (os.environ.get('TRAVIS_EVENT_TYPE') == 'cron' and os.environ.get('TRAVIS_CPU_ARCH') != 'arm64') else 'ci' # noqa: E501
default = 'fuzzing' if (os.environ.get('IS_CRON') == 'true' and os.environ.get('ARCH_ON_CI') not in ('aarch64', 'ppc64le')) else 'ci' # noqa: E501

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.

Could we print this in the pytest header or just directly so it's easy to see in the CI logs ?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Great idea. I added something, let's hope it works.


env:
ARCH_ON_CI: "normal"
IS_CRON: "true"

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Note: We can get fancy by setting IS_CRON using value from Actions github.event_name context (cron = 'schedule') but given that we have split cron into a separate YAML, that seems to be unnecessary.

TST: Add env reporting to test header.

MNT: Remove .travis.yml from labeler.

[ci skip]
@pllim

pllim commented Dec 4, 2020

Copy link
Copy Markdown
Member Author

How does this look, @saimn ?

============================= test session starts ==============================
platform darwin -- Python 3.7.9, pytest-6.1.2, py-1.9.0, pluggy-0.13.1
cachedir: .tox/py37-test-alldeps/.pytest_cache

Running tests with Astropy version 4.3.dev323+gef9139d6c.
Running tests in astropy docs.

Date: 2020-12-04T15:44:05

Platform: Darwin-19.6.0-x86_64-i386-64bit

Executable: /Users/runner/work/astropy/astropy/.tox/py37-test-alldeps/bin/python

Full Python Version: 
3.7.9 (default, Oct 28 2020, 13:24:28) 
[Clang 11.0.0 (clang-1100.0.33.17)]

encodings: sys: utf-8, locale: UTF-8, filesystem: utf-8
byteorder: little
float info: dig: 15, mant_dig: 15

Package versions: 
Numpy: 1.19.4
Scipy: 1.5.4
Matplotlib: 3.3.3
h5py: 3.1.0
Pandas: 1.1.4
PyERFA: 1.7.1.1
Cython: not available
Scikit-image: not available
asdf: 2.7.1

Using Astropy options: remote_data: none.

ARCH_ON_CI: normal
IS_CRON: false

@mhvk mhvk left a comment

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.

Looks very nice, thanks @pllim! (including the added information to the header)

@pllim

pllim commented Dec 4, 2020

Copy link
Copy Markdown
Member Author

Let's merge then. We'll know if fuzzing works or not when cron runs. 🤞

Thanks for the reviews, everyone!

@pllim
pllim merged commit d5976e8 into astropy:master Dec 4, 2020
@pllim
pllim deleted the tst-fuzzing branch December 4, 2020 19:51
pllim added a commit to pllim/astropy that referenced this pull request Mar 23, 2021
TST: Fix hypothesis fuzzing logic on CI
@pllim

pllim commented Mar 23, 2021

Copy link
Copy Markdown
Member Author

I have a manual backport PR open for this at #11409 , does that mean we need to re-milestone this or not? I am not sure. I'll let @eteq figure it out.

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.

3 participants