Mybinder.org-deploy: Henchbot on heroku?

[betatim]

Should/could we deploy henchbot to a heroku instance and run it as a cronjob? We can configure https://github.com/henchbot/mybinder.org-upgrades so that it automatically deploys to the heroku instance when a PR gets merged.

The advantage would be that it is easier for others to make changes and we wouldn't be depending on a piece of hardware in someone's house. It would also be an example that others like Pangeo can follow for running their bot.

Started this because a PR was merged about 8h ago on the BinderHub repo and I was expecting a PR from the henchbot here to deploy it. However there isn't one. This isn't a problem, because there is no hurry and if there were I can make a PR by hand. It just reminded me how much better life with henchbot is and that I don't know how to investigate/restart it when it is not doing its thing ;)

cc @henchc

[betatim]

Actually ... the reason I didn't see the PR was that henchbot and @henchc had already done everything and I overlooked it!! So in this case I should have had an extra sip of coffee.

[choldgraf]

:-)

so, I can't tell if this is an issue for us or not? Is it?

[betatim]

Not sure, the original motivation was "I think henchbot missed something and I don't know how to prod it. Hosting it on a Rpi is cool but what if the internet goes down where the Pi is and the owner goes on vacation?"

Having a quick vote/getting thoughts from people feels worth it. Then we decide what to do next.

I'd put it as a "good way to get started with mybinder.org infrastructure" issue that would be nice to have but isn't urgent.

[choldgraf]

Makes sense to me, I'd be +1 on it

[bitnik]

Today we deployed a bot, which updates GESIS Binder according to mybinder.org, as kubernetes CronJob. I thought it may be also an option for you. Here is the cronjob yaml file that we use: https://github.com/gesiscss/orc/blob/master/gesisbinder/bot/cron_job.yaml

[betatim]

Nice! I think previously we discussed running monitoring bot(s) and the like on the cluster itself or not. My take away from back then (without trying to find the links) was that we thought we don't want to run monitoring or tools to help with deploys on the same infrastructure they are managing.

You could imagine a situation where you are trying to use henchbot to update henchbot but the deployed henchbot is broken so you can't update henchbot via henchbot. (replace henchbot with your favourite mission critical tool)

My opinion: using heroku would be good as it is different from our infrastructure (yay broken at different times...) and it is a few clicks to get the integration with GitHub for automated deploys.

[henchc]

I'm fine either way, I think @yuvipanda also mentioned putting it inside the deployment. I haven't used heroku before, but I assume it's not too hard.

Let me read up on it this week, let me know if anyone is opposed or prefers it inside the deployment :)

[henchc]

Ok, I think I set it up correctly. It's deploying from master here: https://github.com/henchbot/mybinder.org-upgrades

I have it set up with Heroku scheduler: https://devcenter.heroku.com/articles/scheduler#installing-the-add-on

I have it triggering hourly at the :30 , so we'll see if it's as consistent as the :00 on my rpi right now, and then I'll remove it from the rpi

[henchc]

Looks like the Heroku app is working. I've moved it to check every 10 minutes and have stopped my local bot. I'll monitor for the next week and close this issue if things go well.

I also added @betatim to the repo on https://github.com/henchbot/mybinder.org-upgrades . Any changes to master will be deployed to the app. Happy to add others as well.

[choldgraf]

wahoo!

[betatim]

Nice work on getting bots to help us run our bot that helps us ;)

I was wondering the other day: How does henchbot decide that something is ready to be added to a PR for the deploy repo? Can it happen that some of the build processes (docker images, helm charts, etc) aren't done yet when it opens the PR to deploy stuff? Imagine the following timeline: a PR in jupyterhub/binderhub gets merged, the CI job starts building the helm chart, henchbot opens a PR, someone clicks merge, CI job finishes building the new chart.

Till now I thought the chances of ever running into that were small because the bot only runs once an hour and then it takes us a moment to spot it etc. With a 10min cycle this might become something to be aware of?

I think it would be enough for people to know and be "slow" to merge stuff instead of racing. Then we can later extend the bot to make it smarter wrt this stuff (no stress).

[betatim]

ps. would it be Ok to add a few more people from the team to the repo? Just to spread around responsibilities ;)

[henchc]

Good question, we ran into that early on, so now the bot checks Dockerhub for repo2docker and the helm chart for binderhub, so I dont think we should run into premature PRs. In fact I noticed it skipped an hour once after a merge because the build was taking too long, and it got picked up the next hour.

The only way to find out is to give it a shot I guess! We can just rebuild in Travis if something is too early.

And yes , I'll add @sgibson91 and @choldgraf

[sgibson91]

Yay, bots! 🤖

[betatim]

Thanks for the explanation!

I'll close the issue as we have achieved the goal :)