I have a bunch of scripts here:

Not all are useful. Let’s move some over to a shared dev-ops repo.

Unfortunately, I won’t be able to stay for the meeting tomorrow, but if there are questions, please shoot them over.


Could you (Daniel) and Sean coordinate on the handoff?
I think Sean’s on this list, but I’m bcc-ing him just
in case.

  • Bob


Yeah, things I can think of that Daniel and I should probably figure out:

  1. Resource inventory (jenkinses, travis, etc)
  2. Notifications (so I get emailed when things break)
  3. Credentials (so I can log in to fix them)

Not sure how you wanna do it.


Yeah; probably not the greatest to pass this around on a public forum.

We use GitHub permissioning for Jenkins, Travis, and a few other services.

I can give you permissions on every physical box we own and tell you where
they live in real life.

Other stuff: not sure. Let me take inventory first?



Not sure if this warrants its own topic but I made a pull request that failed the travis build here: but I don’t understand why it failed; all of the tests seem to have passed. Does Travis check something besides the exit code to determine if tests have passed?


Another question - Can we turn off the build for OSX with gcc in Travis (because OSX ships with clang)? Just learned how to do that ;)


Travis failing builds: it should just check the exit code, but I think they
try to do something clever. I’ve followed all their online doc, but there
might be more things we can do to make it more reliable. I just don’t know.

Re: gcc in OSX. I think you can kill it now. (create a pull request – it’s
in the .travis.yml) When we first started with Travis, they compilers were
different. Now they’re the same back end. I think we want to continue
testing multiple compiler versions for linux.


Have a PR open to kill it in stan, will make one in cmdstan. stan-math actually doesn’t have gcc listed as a compiler even for linux, is that okay? I think you removed it in May 2015 but it was with a bunch of other nearby changes, not sure if that was intentional. My instinct would be to add it back for just linux so it’s parallel with the other repos but let me know what you think.


yeah – add it back to math. No idea why it was taken off; it might be a time thing, but we’ll know if the pull request doesn’t actually get past Travis.


Interesting - the Linux GCC build doesn’t seem to work for stan-math.. Here’s the error message on one of the two failures:
test/unit/math/fwd/scal/fun/Phi_test.cpp: In function ‘void test_tails() [with T = stan::math::fvar<double>]’: test/unit/math/fwd/scal/fun/Phi_test.cpp:171:29: instantiated from here test/unit/math/fwd/scal/fun/Phi_test.cpp:70:3: error: ambiguous class template instantiation for ‘struct stan::math::ad_promotable<stan::math::fvar<double>, stan::math::fvar<double> >’ ./stan/math/prim/scal/meta/ad_promotable.hpp:30:12: error: candidates are: struct stan::math::ad_promotable<T, T> ./stan/math/fwd/scal/meta/ad_promotable.hpp:13:12: error: struct stan::math::ad_promotable<V, stan::math::fvar<T> >
I’ll start googling; anyone else have ideas?


Know what version of gcc that is? We definitely don’t compile with 4.2.
Probably not with 4.4 any more.


it claims 4.6.3.


Eh… maybe that’s why I turned it off? I wish I could ask my old self what
I was thinking.

Any way we can run that version locally?

P.S. If there’s anything broken or if you can do anything better, please do
it. I take no offense to being told that I did things incorrectly.


No worries. I’ll look into it a bit more.

In the meantime, I think I might need to make a change to one of the stan-scripts to fix this build. Do you think I should copy the stan-scripts folder as a new repo under stan-dev? I think we talked about this being the right move but just wanted to double check.


Please do. Let’s shift anything useful from my repo over to stan-dev. We don’t need the history to persist.

We’ll need to update Jenkins to use the new repo, but I can help with that.

Hopefully you can see the Jenkins backup repo in the stan-dev org. I haven’t had a need to restore from the backup, but it’s there.


Yep, I see the backup repo. How do you update it when jobs change? I’m changing them now to reflect the stan-dev/ci-scripts repo.

Separately, question about the Upstream Update jobs desired behavior - should they fail if there’s an outstanding pull request to do the update? Or should they succeed and print warnings?


Not sure what you mean: “when jobs change.”

For the upstream jobs, I wanted it to just keep updating the pull request until it’s merged. Most if the time, it won’t affect the upstream build. There shouldn’t be any git conflicts. Unless we do something crazy, the upstream jobs aren’t affected by changes downstream.


Sorry, was asking how you would update the Jenkins backup repo when changes are made to the Jenkins config - I don’t see any git repos in /Users/Shared/Jenkins that might be used for the purpose, was wondering if you have a script for that or what the procedure has been.


Ah. Now the question makes sense.

I hacked it together. It’s in the config of the Jenkins job. There’s a curl in there as a step that grabs the script. I couldn’t find a better way to do it at the time using Jenkins plugins.

Any thoughts on how to make that better?


Ah, I’ve seen that but wasn’t talking about that either :P Sorry for confusion. I haven’t thought of any better way just yet.

I was saying that I can see the jenkins-config repo that seems to back up the jenkins config, and I was wondering how you update that repo when the config changes?