Re: [ANNOUNCE] git-scm.com Heroku credits update

[Taylor Blau <me@ttaylorr.com>]

On Thu, Apr 07, 2022 at 11:54:18PM +0200, Johannes Schindelin wrote:
> > To that end, we have a few options about what to do with the website in
> > the future:
> >
> >   - Convert the Rails application into a static site that could be
> >     hosted elsewhere for free. The non-static portions of the site would
> >     have to become static in one way or another, and we'd have to come
> >     up with an alternative search mechanism to replace the existing one.
>
> This is my preference (and I would love to contribute the time, but am
> quite short on that resource to help much).
>
> It looks to me as if the only blocker is the site-search, and there are
> ways to pre-generate an index e.g. in a Jekyll site (which we could host
> on GitHub Pages, incidentally, which would be a very nice setup indeed).

There are a few other smaller-ish things that we are using Rails for.
But most of them are limited to "fetch this list of things from Postgres
and format it in HTML" which could easily be automated and checked into
the static version of git-scm.com's repo.

> The other thing the Rails app does is to regularly poll for updated
> versions, e.g. Git for Windows and Git for Mac. This strikes me as
> something that would benefit from the transparency provided by having a
> GitHub workflow to perform said polling instead of the opaque Rails app on
> Heroku with no public log of when it ran and whether it was successful.

Yeah, agreed. Another "behind the scenes" task is running:

    heroku run -a git-scm rake preindex
    heroku run -a git-scm rake downloads
    heroku run -a git-scm rake search_index

, which I do after Junio pushes new tags. (FWIW, these jobs should run
on a timer, too, but I like to update the site with new links around the
time a release is tagged as opposed to having to wait for the automated
job to kick off).

I imagine that this would be replaced with some kind of GitHub workflow,
and the result (any new pages, updated search indexes, etc.) would be
committed into the repository transparently. That workflow could be
automated as well and get kicked off when new tags are pushed to git/git
(I think).

Thanks,
Taylor