DRAFT - Why do we use travis to build the website?

[dellagustin]

I will elaborate later, at the moment it is pointer to myself.

References:

• https://github.com/InnerSourceCommons/innersourcecommons.org/blob/ba60fcf58569c9fdce84d723918c8e7f743585f6/cibuild
• https://jekyllrb.com/docs/github-pages/
• https://help.github.com/en/github/working-with-github-pages/setting-up-a-github-pages-site-with-jekyll
• https://github.com/dellagustin/dellagustin.github.io

[rrrutledge]

Transitioning to GitHub pages native build sounds great. The only thing preventing would be if there were some Jekyll plugins that were not supported by GitHub pages.

[dellagustin]

@rrrutledge this was actually triggered by your comment on #119 => InnerSourceCommons/innersourcecommons.org#119 (comment) 😃

I was already asking myself why we used travis (makes sense for automated checks on PRs) to build the webpage, as based on my past experience the pages were generated automatically by GH.
I created this issue to do an analysis and eventually propose the switch into GH pages (or not, depending on the result of the analysis).

[rrrutledge]

Sounds great! Propose away! Let's do this!

[lenucksi]

This is related to #67

• The initial reason for Travis was probably "because it's there and I know it" coupled with "we need the bit of extra plugins" @cewilliams might know more.
• There are multiple variations of no-maintenance + no-involvement builds with bells & whistles available from the GitHub Actions market. Take a look here: https://github.com/marketplace?type=actions&query=jekyll
  • Bells and whistles being extra plugins, PR checks, all sorts of static site gens, and whatever one could think of.
• GitHub actions is already active in our repo. And could even serve the stage / prod build we talked about in the Docker thing.