Travis tweaks #1596
Comments
|
Original Redmine Comment Looks good. Feel free to continue to ask, but also feel free to push any travis or other changes you feel reasonably confident in. |
|
Original Redmine Comment 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: CMake is also complaining in that build: 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. |
|
Original Redmine Comment I think we should aim to allow 14.04, or at least plan to until we find something painful. Thanks for diagnosing etc. |
|
Original Redmine Comment 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: Doing so seems better than requiring the repo to support Python 3.4 because that version of Python is apparently no longer supported: 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. |
|
Original Redmine Comment 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. |
|
Original Redmine Comment 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. |
|
Original Redmine Comment In 4.024. |
veripoolbot
added
area: tests
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
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.
The text was updated successfully, but these errors were encountered: