-
Notifications
You must be signed in to change notification settings - Fork 161
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
BuildPackages.sh: add option to abort upon failure #2022
BuildPackages.sh: add option to abort upon failure #2022
Conversation
With --strict given, BuildPackages.sh immediately aborts with a non-zero exit code if there are any errors building a package. This way, it can be used effectively from other scripts, e.g. for package's Travis tests.
BTW, I did verify locally that the exit code handling works, but I don't see a good way to add a test to the GAP test suite for it. However, I plan to adapt multiple packages to take advantage of this feature ASAP, so that will effectively test it. See e.g. gap-packages/FactInt#5 and gap-packages/ZeroMQInterface#18 (and many more to come, once this PR here is merged) |
Codecov Report
@@ Coverage Diff @@
## master #2022 +/- ##
==========================================
- Coverage 66% 66% -0.01%
==========================================
Files 898 898
Lines 273268 273267 -1
Branches 12745 12745
==========================================
- Hits 180378 180377 -1
+ Misses 90071 90069 -2
- Partials 2819 2821 +2
|
https://travis-ci.org/gap-system/gap-docker-master-testsuite is another place where I will use it. Totally support adding this to GAP 4.9.0. |
@alex-konovalov then perhaps approve & merge? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not run it, but the changes look OK, and I trust @fingolfin's tests. This is useful.
With --strict given, BuildPackages.sh immediately aborts with a non-zero exit code if there are any errors building a package. This way, it can be used effectively from other scripts, e.g. for package's Travis tests.
It would IMHO be highly desirable to get this into the
stable-4.9
branch, so that packages can use a uniform test setup for both the stable and master branches.