[WIP] Build: update travis ruby version

[bitschmidty]

Updates travis' ruby version.

Fixes #1437

NOTE: We use ruby 2.6.4 throughout the setup and build process separately from travis. I may make additional commits to update those to 3.2.2.

[harding]

I tested this and had some problem with nokogiri, which seems like it may have been a local issue. I then started building on top of this to upgrade to the latest Jekyll version. Upon getting that working (with some errors that still needed to be resolved), I discovered it was a major performance regression in the --incremental build mode, which I use often to save time while editing the newsletter. Digging it, I quickly realized that Jekyll is basically abandoned; it's only getting infrequently bug fix releases.

I'm currently considering looking at an alternative static site generator (Hugo), but if anyone has an opinion about the future of rendering the site, now is the time to voice it!

[murchandamus]

This is a bit out of my wheelhouse, so no strong opinions on it. I successfully leveraged using Hugo for my own website with surprisingly little effort, but I cannot say anything about how easy it would be to migrate a large project like the Optech site to Hugo.

[harding]

I cannot say anything about how easy it would be to migrate a large project like the Optech site to Hugo.

I did a few hours of research and PoC-level testing and part of it does look like a pain---but I also researched (more briefly) several other static site generators and none of them looked to be both well-maintained and easier to convert from Jekyll than Hugo.

I'm currently thinking of the following approach:

1. Keep all source files where they are.
2. Compile the site with Jekyll exactly like we do now.
3. Run a script that copies some source files into a hugo-specific directly. Have the script also transform the copied files as necessary
4. Run hugo on the file copies
5. Overwrite any jekyll-generated output files with any hugo-generated output files (but keep any files that are generated only by jekyll)
6. Continue running all of our QA tests on the output to minimize the risk of breakage

This should let us transition slowly and over an extended period of time. Eventually one day we'll have everything transitioned over to hugo and we can make the change permanent.

[bitschmidty]

Ive heard good things about hugo, but have not used it personally. Happy to test if there is such an intermediate script.

I assume none of these worked "magically" in terms of conversion since we have a bunch of custom adds:
https://gohugo.io/tools/migrations/#jekyll

[harding]

@bitschmidty I didn't try any of those scripts; I just assumed they wouldn't work given our custom plugins.

I've been working on the conversion a few hours a week and I'm fairly pleased so far. I've ported over our auto-anchor plugin, which seemed like it would be the hardest bit, and now I'm just playing wack-a-inconsistency with other differences between Jekyll and Hugo. For all the English-language newsletters and topic pages, plus a few pages in Spanish for testing, here's the current compile time stats:

Template Metrics:

     cumulative       average       maximum         
       duration      duration      duration  count  template
     ----------      --------      --------  -----  --------
   3.486254208s    8.380418ms   26.787722ms    416  partials/auto-anchor.html
   2.726568369s    9.467251ms   27.004894ms    288  _default/single.html
   2.230547681s    3.767817ms   15.547544ms    592  shortcodes/references.md
   1.957914591s   15.296207ms   37.307749ms    128  topics/single.html
    44.945128ms     131.418µs    2.402658ms    342  shortcodes/linkers/issues.md
    42.956292ms      96.314µs     9.59795ms    446  partials/footer.html
    40.077951ms       89.86µs     366.353µs    446  partials/header.html
    32.212289ms    1.342178ms   11.670321ms     24  _default/list.html
      3.73004ms     1.86502ms    3.668056ms      2  _internal/_default/sitemap.xml
      968.025µs      10.408µs     209.034µs     93  _internal/alias.html
      855.574µs     213.893µs     503.661µs      4  _default/terms.html
      332.627µs      30.238µs      35.628µs     11  shortcodes/snippets/recap-ad.md
      257.151µs     128.575µs     173.507µs      2  404.html
      244.382µs         547ns      37.712µs    446  partials/foot_custom.html
      200.979µs         450ns      11.114µs    446  partials/head_custom.html
       90.289µs      90.289µs      90.289µs      1  _internal/_default/sitemapindex.xml


                   | EN  | ES  
-------------------+-----+-----
  Pages            | 442 |  4  
  Paginator pages  |   0 |  0  
  Non-page files   |   0 |  0  
  Static files     |   2 |  2  
  Processed images |   0 |  0  
  Aliases          |  93 |  0  
  Sitemaps         |   2 |  1  
  Cleaned          |   0 |  0  

Built in 1263 ms

In other words, using parallel compiling, the primary site content compiles in 1.3 seconds. I expect that to slow down when we add in the translations and the long transcript pages, but it should still be significantly faster than Jekyll.

I'll keep working on it and hope to have a preview PR up in a week or two so we can begin discussing some related changes.

[bitschmidty]

@harding thanks for working on this! Let me know how I can help (grunt work, or finding volunteer help?) or help test.

Im going to close this PR, which is an attempt to fix #1437 since the approach in this PR (keep jekyll, upgrade ruby) is not our current approach (Hugo)