ryankeleti
Site deploy
We run Kerodon on PythonAnywhere, which takes away the hassle of all administration. The only thing is that to run a website on a custom domain, you need to pay $5 / month, which might not be ideal for you.
Site is back up (for now). I need to find a more permanent fix though...
@pbelmans PythonAnywhere seems neat! I'm currently just using a script + cronjob + other hackery on my personal server, which isn't the most stable solution. Did you have any setup problems or was it pretty straightforward?
It's really straightforward in my experience. Their infrastructure is set up (amongst other things) for Flask, so the configuration is easy.
The update process might not be fully automatable: in the case of Kerodon it consists of
- building the pdf locally
- running plasTeX and building the database locally
- uploading the files via the web interface of PythonAnywhere (maybe this is scriptable though?)
- triggering a restart of the server
For Kerodon this only happens once a month at most, so it's not so much of a hassle then.
Site is back up (for now). I need to find a more permanent fix though...
Is it using the most recent files? I can't see EGA II§3 on the html version, but it appears in the PDFs
@thosgood I'll check up on that...
@pbelmans Ah I see, so most of it is manually done. My script watches for changes to the repo and autobuilds/redeploys. I haven't spent the time to make it very resilient to stuff which may break the build (say, ill-formed LaTeX) which is my main concern. I'll take a look at PythonAnywhere and see if I can make it fit this model somehow. It would be nice to let others have control over the build in case I'm unavailable to fix it.
The "nice" thing with not having an autobuild is that there's nothing to fix if it ain't broken :). Of course, it also means that, if you're not available, no-one is updating it.
I would imagine integrating PythonAnywhere into an automated pipeline is possible, I just never felt the need, as I spend quite some time making sure Jacob's large updates are all rendering correctly, and very little uploading the updated files (i.e. the pdf and the database). The diagrams in Kerodon are so much more complicated than the ones in EGA, making that for instance a rather subtle thing to get right on the web, but you don't have this problem.
have you thought about running the build through github actions @ryankeleti ? I've been using this for a bunch of projects over the past few years, and I'm debating moving my translations project to this as well, so I don't have to worry about my own server. one nice feature is then any admin for this repo can fix the builds if they go down (and you can also implement build checks before allowing PRs to be merged, for example)
I could start taking a look at this — I've managed to convince github actions to build pdfs from latex source code in the past, after some fiddling around. Do you have a copy of the script your server currently runs, or could you sketch out what it does? I've never used gerby/plastex before so am not familiar with the build process
@thosgood The LaTeX generation should be straightforward (I can report back on what script I use). On the other hand, gerby uses flask so you'd need a server to run it on
@ryankeleti I've just finished EGA II (🎉 ) so if there's an easy way to manually trigger a rebuild of the web version, this would be cool (but there's no real rush!)
(not sure if this deserves its own issue, but just to point out that the autobuild PDFs seem to be building every hour, even if no changes have been made to the source .tex files)
@thosgood Nice! I didn't expect that, seems you've been chipping away at it for a while! Sorry I've been so busy lately and haven't gotten around to this issue. I can't remember why I started doing hourly rebuilds, probably for some weird reason. I really want to figure out some kind of GitHub actions approach to this so we don't have to rely on some hidden script that breaks every so often..
no need to apologise! as for an actions solution, I guess a pretty concrete plan could be as follows:
- copy whatever script your server runs into a script in this repository
- turn your server (or mine) into a github actions runner (I've done this a few times, and it's pretty speedy to setup)
- make a workflow that just runs the script using that server every time there's a push to
main(again, I already have a template for this, so also not a big hassle)
the bonus good thing about running this through actions is that we don't need to get a server to continuously check whether or not there have been any changes (or worry about webhooks) — you can just get the action to run on pushes/merges into main!