Skip to content
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

Travis tweaks #1596

Closed
veripoolbot opened this issue Nov 12, 2019 · 7 comments
Closed

Travis tweaks #1596

veripoolbot opened this issue Nov 12, 2019 · 7 comments

Comments

@veripoolbot
Copy link

@veripoolbot veripoolbot commented Nov 12, 2019


Author Name: Todd Strader (@toddstrader)
Original Redmine Issue: 1596 from https://www.veripool.org

Original Assignee: Todd Strader (@toddstrader)


See:
https://github.com/toddstrader/verilator-dev/tree/travis-tweaks
and:
https://github.com/toddstrader/verilator_ext_tests/tree/travis-tweaks

I've done essentially the same thing to both codebases. Namely, I've fixed the issue Travis had expanding

VERILATOR_NUM_JOBS=$((`nproc` + 1))

And I've added what I hope will notify me about build failures in the main repo.

The former works correctly, but that latter will require testing. I believe my change will send me (and anyone else added to the list) emails when any branch in the main repo (I don't want to get emails about forks) has a failing build or when it transitions from failing back to passing. To test this, I'd like to push this branch to the main repo, intentionally break the build (in the branch) and then fix it up. I should get emails for all of this. I can then delete the branch to clean up.

Please let me know what you think and I can proceed with testing. Also, I can land these commits together or independently.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 12, 2019


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-11-12T11:29:13Z


Looks good. Feel free to continue to ask, but also feel free to push any travis or other changes you feel reasonably confident in.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 13, 2019


Original Redmine Comment
Author Name: Todd Strader (@toddstrader)
Original Date: 2019-11-13T13:24:33Z


Great, I'll keep that in mind. I've gone down a bit of a rabbit hole here and am cleaning up a few more things. One thing I found is that we weren't actually running on Trusty machines as I had intended. When I fixed that, I found that t_a4_examples is broken on that distribution because examples/xml_py/vl_file_copy uses the allow_abbrev parameter for argparse which wasn't added until Python 3.5 but the Travis Trusty machines have 3.4.3:
https://travis-ci.com/toddstrader/verilator-dev/jobs/255879351

CMake is also complaining in that build:

CMake Error: Problem processing arguments. Aborting.

And I don't yet know why, but I'm guessing it's probably because of an older version of CMake on there too.

I'm going to resolve these for now by skipping them if Python/CMake don't meet whatever versions are needed. But the question is, do we want these things to work out of the box for Ubuntu 14.04, which apparently isn't end of life until April 2022. If so, I can open some more issues based on what all I find.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 13, 2019


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-11-13T13:28:29Z


I think we should aim to allow 14.04, or at least plan to until we find something painful.

Thanks for diagnosing etc.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 13, 2019


Original Redmine Comment
Author Name: Todd Strader (@toddstrader)
Original Date: 2019-11-13T21:38:19Z


The other option here is to install Python 3.5 on the Trusty image. This is the latest version of Python3 that Ubuntu 14.04 has. And this resolves the issue:
https://travis-ci.com/toddstrader/verilator-dev/jobs/256291128

Doing so seems better than requiring the repo to support Python 3.4 because that version of Python is apparently no longer supported:
https://docs.python.org/release/3.4.10/

The downside is that it takes 3-4 minutes for apt to download the Python packages because the Travis connectivity is slow/throttled. However, I think this is better than requiring people to code to a version of Python which is no longer supported.

I suggest we go the Python 3.5 route. Wilson, do you agree, or do you think we should make sure the code works on Python 3.4? And if we go the Python 3.5 route, should we put a check in configure for Python3 >= 3.5? I'm not that familiar with autoconf so I don't know if that's the best place to do it.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 13, 2019


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-11-13T22:56:33Z


That example isn't terribly important. I suggest I just only run it if python is new enough, rather than take the 3 minutes. If something more critical breaks the 14.04's python we'll then know.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 14, 2019


Original Redmine Comment
Author Name: Todd Strader (@toddstrader)
Original Date: 2019-11-14T23:04:35Z


Squashed and pushed to both repos. I added some Makefile logic to examples/xml_py to skip the example if Python < 3.5. I'm also going to add a few follow-on issues to keep track of a few other things I noticed but am not getting to immediately.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Dec 8, 2019


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-12-08T13:13:16Z


In 4.024.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.