Skip to content
This repository has been archived by the owner on Feb 25, 2024. It is now read-only.

Assertion builds #90

Closed
staticfloat opened this issue Oct 3, 2018 · 7 comments
Closed

Assertion builds #90

staticfloat opened this issue Oct 3, 2018 · 7 comments

Comments

@staticfloat
Copy link
Member

Julia and LLVM have debug assertions that we can enable for better error reporting. It would be good to have PRs and pushes get put through the ringer of "assertion" builds, and also for users to be able to use assertion builds. And so here is my master plan:

We create two schedulers: the PR scheduler, and the push scheduler. They are identical, except for the fact that the push scheduler adds a [release] tag, which means that this build should eventually get promoted, instead of just being tested and then left to rot. (Side note; if at all possible, we should customize our GitHub statuses so that users can download the build artifacts right there from the PR CI screen)

Each scheduler kicks off two builds; one with assertions and one without. Both will get uploaded, both will get tested, both will get promoted (if they have the [release] tag). We then change travis and appveyor to have new default versions. We'll support the following:

julia:
  - 1.0
  - 1.0-assert
  - 1.0-noassert
  - nightly
  - nightly-assert
  - nightly-noassert

Where 1.0 is an alias for 1.0-noassert, and nightly is an alias for nightly-assert. In this way, we get:

  • Greater flexibility, by providing users the ability to opt out of asserts on nightly builds if they need to.

  • Greater coverage with assertions when testing both base Julia and the package ecosystem (for those packages that are already testing the waters with nightly, but leaving alone the poor packages that just want to make sure their single-line test suite passes on 1.0)

  • Greater AWS storage costs because we now store every build twice.

What do you guys think? @vchuravy @iblis17 @ararslan

@vchuravy
Copy link
Member

vchuravy commented Oct 3, 2018

I think this is a good idea, but I would generally differentiate between CI/CD and release builds. For CI/CD since it sometimes is hard to understand why a issue occurred having assertions is very valuable and the performance cost is ok. On the other hand for official releases we shouldn't enable asserts. I would even go further and say that for CI/CD we only should have asserts builds, with downstream CI pulling those assert builds.

So we should only have two builds for [release] and a single assert build for nightly, and Travis should not get a choice and use the assert builds throughout.

cc: @vtjnash

@staticfloat
Copy link
Member Author

staticfloat commented Oct 4, 2018 via email

@vchuravy
Copy link
Member

vchuravy commented Oct 4, 2018

I do all my performance testing on the ASSERT configuration. Also asserts slow down the runtime and the compiler but not generated code.

@staticfloat
Copy link
Member Author

So perhaps what we should do is build two of both, use assert versions for all Travis/Appveyor type things, and then link to the nonassert versions from the main JuliaLang downloads page; so that things downloaded by a human tend to be fast to compile, but anything automated is properly checked. I can imagine people being upset that the version they download from the web is (measurably) slower than what they get by building from source due to assertions.

@vchuravy
Copy link
Member

vchuravy commented Oct 4, 2018 via email

@ararslan
Copy link
Member

ararslan commented Oct 6, 2018

While I'm generally supportive of having multiple builds available, I'm a bit skeptical of having package CI running a different Julia binary than an average user would download and use locally. I think release builds with assertions enabled on CI should be opt-in, with assertions enabled for nightly. We can make clear on the downloads page that nightly builds have slightly different settings than releases so that users have a better idea of what they're getting and what to expect.

For reference, FreeBSD's master/nightly builds has a lot of debugging information enabled by default and they document that it will be slow because of this, and that you have to build it yourself with specific options to disable the things that make it slow. (That's what I do on my desktop partition.) That seems like a good model to follow for us.

So I'd suggest:

  • Release builds have no assertions. CI will use these by default.
  • We have alternate release versions with assertions. CI can opt into using these.
  • Nightlies always have assertions.

While having multiple builds for each release version kind of sucks, I'd be interested to see what the difference is between having multiple binaries and the days when our binaries included a full debug build in terms of file size/storage cost.

@staticfloat
Copy link
Member Author

Closed by #111

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants