Use binder for reviewing trac tickets

[saraedum]

I have been working on enabling CircleCI/GitLabCI in the sagemath repository. As one application, I am now playing with automatically setting up sage-binder-env branches from CI for every build. My idea is that this could allow people to include a "launch on binder" badge on trac tickets so that code changes can be tried out by reviewers without actually having to build the code.
Have you considered such an application? What do you think about it?

[saraedum]

I have a first version of this. https://github.com/saraedum/sage-binder-env/tree/binder is generated automatically with every commit to my github branches. @roed314 @xcaruso

[nthiery]

I have been working on enabling CircleCI/GitLabCI in the sagemath repository. As one application, I am now playing with automatically setting up sage-binder-env branches from CI for every build. My idea is that this could allow people to include a "launch on binder" badge on trac tickets so that code changes can be tried out by reviewers without actually having to build the code. Have you considered such an application? What do you think about it?

I had not considered such an application, and this sounds like an excellent idea! It indeed would be super useful for reviewers to be able to play with the code live without having to install/compile/... The only caveat is: how much computing power would this consume? Would *CI be willing to provide it? Would there be strategies to reduce that consumption? In particular, are recompilations "relative" to the previous commit? Secondary question: could we run a variant of the patchbot to test the result of the compilation and report?

[saraedum]

The only caveat is: how much computing power would this consume? Would *CI be willing to provide it?

*CI provides every user with plenty of resources (~ 4 concurrent builds.) The problem is that the commits have to belong to that user, i.e., they have to come from their github/gitlab/bitbucket repository. (I could imagine that we could extend git trac to push to a corresponding github/… repository on every git trac push but I am not sure I like that idea.)
GitLab CI allows us to provision our own runners, so we could have as many as we want to pay for or volunteers want to provide.

Would there be strategies to reduce that consumption?

A build takes at the moment 35 minutes on CircleCI / 50 minutes on GitLab CI. I know how to bring the first number down to 25 minutes but I don't think it's worth it. Essentially the same goes for the second number.

In particular, are recompilations "relative" to the previous commit?

They are at the moment relative to the latest build of the develop branch, i.e., your branch needs to have develop merged in which is a good practice anyway to avoid merge conflicts in the future.

Secondary question: could we run a variant of the patchbot to test the result of the compilation and report?

You mean something like this?

In principle yes. However, it is a bit annoying to make this work in trac.

For the short term I think that a few people who like this, should just try to use it. If it turns out to be actually stable and useful, more people are going to want this for their tickets. Eventually we can patch git trac or Trac or begin the migration away from Trac…whatever seems the right move then.

[saraedum]

This is now tracked at https://trac.sagemath.org/ticket/24842.

[kwankyu]

This old issue seems to have been fulfilled in sagemath/sage#24842 when we were on trac. I don't remember, but presumably there were binder badges on trac tickets. I don't know the current status of the scripts(which I could not find) in our codebase.

Now that we are on github, I created sagemath/sage#36245 to do the same or something close. Please visit and give comments. It is not yet in "needs review" as the binder badge fails to build sage (incrementally), because of some defect of our current beta.

Anyway, this issue is outdated and there is nothing to do here about it. Hence I close it.