Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set up documentation website generation and deployment #253

Merged
merged 28 commits into from
Oct 4, 2022

Conversation

japborst
Copy link
Member

@japborst japborst commented Sep 21, 2022

Scope
The scope of this PR is to bootstrap a documentation website.

  • Readme how to run/use the Jekyll website
  • GitHub action to deploy automatically upon merge to master
  • Has a homepage (identical to README.md from GitHub)

Follow-ups
We exclude auto-generating the docs, which will be done in a follow-up PR.

  • Lists all BugPattern checks
    • Displays summary, description, severity, and tag (currently dummy values)
    • Displays source code link
    • In-line replacement examples
  • Lists all Refaster templates (grouped per collection)
    • In-line replacement examples
  • Support additional Markdown docs

Preview
image

@japborst japborst requested a review from rickie September 21, 2022 08:32
@japborst japborst force-pushed the sschroevers/deploy-to-github-pages branch from e9e37c8 to ccf3ce4 Compare September 21, 2022 09:33
Comment on lines 4 to 6
#branches: [$default-branch]
branches:
- 'sschroevers/deploy-to-github-pages'
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before merging, this needs to be reverted.

@japborst japborst temporarily deployed to github-pages September 21, 2022 09:34 Inactive
Comment on lines 23 to 22
- name: Generate documentation
run: bash ./generate-docs.sh
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything is standard in this workflow, except for running the doc generation

<source media="(prefers-color-scheme: light)" srcset="logo.svg">
<img alt="Error Prone Support logo" src="logo.svg" width="50%">
</picture>
<picture>
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A pity, but when using the readme for our website, you can't mix HTML and Markdown. That is normal behaviour, but apparently was okay on GitHub's flavoured Markdown before.

@@ -0,0 +1 @@
There's not much use to keep empty methods.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Used as an example for additional docs on a bugpattern. We should improve this, or use another example.

@japborst japborst temporarily deployed to github-pages September 21, 2022 09:51 Inactive
generate-docs.sh Outdated
Comment on lines 9 to 10
REFASTER_FOLDER="${WEBSITE_FOLDER}/refastertemplates"
REFASTER_DOCS_FOLDER="${DOCS_FOLDER}/refastertemplates"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So IIUC the idea right now is to have one top-level page for each refaster template collection. It would be nice then to enumerate the constituent templates on each pages, accessible through a URL anchor. See the example URL in #255.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed. It's intended to list the template collections per page, instead of a page per template. @oxkitsune is working on retrieving and exposing the before/after templates.

@japborst japborst temporarily deployed to github-pages September 24, 2022 11:44 Inactive
@japborst japborst temporarily deployed to github-pages September 27, 2022 08:21 Inactive
Copy link
Member

@rickie rickie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a commit :).

@@ -0,0 +1,10 @@
# Jekyll generated files
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want these entries here or in the root .gitignore?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Used www.gitignore.io to add some more dirs and files related to Jekyll.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would personally put here, easier to manage and scoped to the website. Where the root gitignore is more focussed on the Java development

exclude:
- Gemfile
- Gemfile.lock
- README.md
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had to add vendor here because I got an issue while generating. Related GH thread.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting... I did not have that issue 🤔

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have this issue either. And I also don't see the .bundle and vendor directories mentioned in the .gitignore 🤔

@rickie
Copy link
Member

rickie commented Sep 27, 2022

(Oops, did it on gdejong/docgen, will move it ~later)

@japborst japborst force-pushed the sschroevers/deploy-to-github-pages branch from 4736144 to 2708207 Compare September 27, 2022 15:09
<picture>
<source media="(prefers-color-scheme: dark)" srcset="website/assets/images/logo-dark.svg">
<source media="(prefers-color-scheme: light)" srcset="website/assets/images/logo.svg">
<img alt="Error Prone Support logo" src="website/assets/images/logo.svg" width="50%">
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed the path to the website assets for the logo, s.t. we only store it in 1 place,

@japborst japborst marked this pull request as ready for review September 27, 2022 15:11
@japborst
Copy link
Member Author

As the documentation generation will be done in the scope of https://github.com/PicnicSupermarket/error-prone-support/tree/gdejong/docgen, I removed it from this PR.

That means this PR focusses just on bootstrapping the website, and is now ready for your review @rickie @Stephan202.

website/_config.yml Outdated Show resolved Hide resolved
@japborst japborst added this to the 0.4.0 milestone Sep 28, 2022
Copy link
Member

@rickie rickie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a commit with some changes. Feel free to tweak them.
The README nicely explains how to start working on the website as well. Used it to set it up locally and works like a charm.

This is such a cool setup! I really like how the website looks and what we can do with it ❤️!

I'm following this ticket for when we can use a title + logo in the top left corner haha.

Thanks for all the effort 🚀 !!!

Suggested commit message:

Set up documentation website generation and deployment (#253)

Generating the website is done by Jekyll with a theme called `just-the-docs`. 
Deployment of the website is done via GitHub Pages.

See:
- https://github.com/jekyll/jekyll
- https://github.com/just-the-docs/just-the-docs

.github/workflows/build.yaml Outdated Show resolved Hide resolved
description: >-
Error Prone extensions: extra bug checkers and a large battery of Refaster templates.

remote_theme: just-the-docs/just-the-docs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we pin the version? As described here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not looking to pin to an older version, as the newer version has some improvements I'd like to have included. We can pin, but does increase maintenance of upgrading. I'm fine with both directions here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like we can use the Gemfile instead. The only difference I see locally is that with v0.4.0.rc2 the "quote" in the readme doesn't have a grey bar on the left hand side. I guess that's only fixed in a non-released version.

Since using the Gemfile (a) reduces maintenance (assuming we set up Renovate) and (b) obviates the need for jekyll-remote-theme: let's go with that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, the build now fails with Could not find 'just-the-docs' (>= 0) among 148 total gem(s) (Gem::MissingSpecError). I guess there's a difference between my local and the GHA setup. To be investigated.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIUC it happens because this image doesn't run bundle install. That would also mean that the Gemfile contents are misleading. This comment suggests an alternative approach. Not sure I'll get around to trying this today still, though...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most actions run in the scope of a Docker image IIUC, so that means indeed bundle install of our own gemfile isn't run 😞

.github/workflows/deploy-website.yaml Outdated Show resolved Hide resolved
destination: ./_site
- name: Upload website artifact
uses: actions/upload-pages-artifact@v1.0.3
deploy:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be clearer to have a newline between these two parts.

Copy link
Member Author

@japborst japborst Sep 28, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indentation already takes care of that. We also don't do that above, or in build.yaml.

generate-docs.sh Outdated Show resolved Hide resolved
generate-docs.sh Outdated
sed $SEDOPTION 's/srcset="website\//srcset="/g' ${HOMEPAGE}
}

# Do it
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can either remove this comment or say something like:

# Start generating the website.

website/_config.yml Outdated Show resolved Hide resolved
website/_includes/head_custom.html Outdated Show resolved Hide resolved
website/_sass/custom/custom.scss Outdated Show resolved Hide resolved
@rickie rickie force-pushed the sschroevers/deploy-to-github-pages branch from 702b589 to db95b9c Compare September 28, 2022 18:30
@rickie
Copy link
Member

rickie commented Sep 28, 2022

Rebased.

@japborst
Copy link
Member Author

Thanks @rickie. I tweaked the suggestions a little.

Let's go 🎸

Copy link
Member

@rickie rickie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, tweaks look good to me!

.github/workflows/build.yaml Outdated Show resolved Hide resolved
@japborst
Copy link
Member Author

japborst commented Oct 1, 2022

I added two things, which I believe were important to do for the website

The latter actually caught quite some invalid urls in our readme, as relative paths won't work when hosting our site.

FYI @rickie as this was added after your review

- name: Validating HTML output
uses: athackst/htmlproofer-action@main
with:
check_external_hash: false
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In some websites a hash is used for JS routing, which is done after loading. Disabling this to reduce false-positives.

@@ -223,5 +221,5 @@ guidelines][contributing].
[pitest-maven]: https://pitest.org/quickstart/maven
[pr-badge]: https://img.shields.io/badge/PRs-welcome-brightgreen.svg
[refaster]: https://errorprone.info/docs/refaster
[refaster-templates-bigdecimal]: error-prone-contrib/src/main/java/tech/picnic/errorprone/refastertemplates/BigDecimalTemplates.java
[refaster-templates]: error-prone-contrib/src/main/java/tech/picnic/errorprone/refastertemplates/
[refaster-templates-bigdecimal]: https://github.com/PicnicSupermarket/error-prone-support/blob/master/error-prone-contrib/src/main/java/tech/picnic/errorprone/refastertemplates/BigDecimalTemplates.java
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absolute paths are required, as the same page is used to service our website.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clear! (I should probably just test this, but) will the build fail if we accidentally reintroduce a relative URL?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly why I introduced html-proofer s.t. we catch this stuff (didn't know the existence before, but came across in another repo and a very obvious check to introduce).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Certainly! (And we shouldn't stop there. I made a note to also introduce shellcheck. We should likely enable other kind of static analysis.)

@japborst
Copy link
Member Author

japborst commented Oct 1, 2022

Open question @Stephan202 (?)

Should we build on all branches, and only deploy on the default branch? Would allow verifying things work (e.g. html proofer and page generation).

@Stephan202 Stephan202 force-pushed the sschroevers/deploy-to-github-pages branch from 584251d to d295e60 Compare October 2, 2022 16:03
Copy link
Member

@Stephan202 Stephan202 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rebased and added a commit. Very nice work @japborst!

I'm not quite done reviewing, but thought I'd flush the changes and questions I have so far.

website/Gemfile Outdated
Comment on lines 1 to 5
source "https://rubygems.org"
gem "github-pages", "~> 227"
gem "rake", "~> 13.0" # Required for "just-the-docs" theme.
gem "jekyll-sitemap", "~> 1.4"
gem "html-proofer", "~> 4.4"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Badbond now we should also consider enabling Renovate support for Gemfiles 😄

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

^ Since I love maximally reproducible builds, I propose to pin the exact versions. I.c.w. Renovate that shouldn't be an issue.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Supporting Renovate here would also allow upgrading gemfiles in other codebases, like iOS.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Created internal ticket to track this 👍.

- README.md
- vendor

permalink: pretty # Use /doc/ instead of /doc.html.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general it does a bit more than that. (But I can see how the date components are omitted in this case.)

Comment on lines 22 to 24
# Theme configuration.
search_enabled: true
heading_anchors: true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are the default values, IIUC. We generally omit defaults; would suggest we do the same here.

Comment on lines 9 to 11
plugins:
- jekyll-remote-theme
- jekyll-sitemap
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upon further reading, it seems that while we don't need to specify these in Gemfile, doing so would improve control over the build.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only for jekyll-remote-theme. We still do need to specify jekyll-sitemap.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Current code work without it. (That said, I should have dropped this comment before flushing: we unconditionally depend on many jekyll-* gems, so singling out jekyll-sitemap doesn't make much sense.)

description: >-
Error Prone extensions: extra bug checkers and a large battery of Refaster templates.

remote_theme: just-the-docs/just-the-docs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like we can use the Gemfile instead. The only difference I see locally is that with v0.4.0.rc2 the "quote" in the readme doesn't have a grey bar on the left hand side. I guess that's only fixed in a non-released version.

Since using the Gemfile (a) reduces maintenance (assuming we set up Renovate) and (b) obviates the need for jekyll-remote-theme: let's go with that.

website/_sass/custom/custom.scss Show resolved Hide resolved
Comment on lines 1 to 3
// We should override $nav-width(-md), however this breaks code highlighting and other styles.
// This seems to be an issue for following the recommended approach.
// See https://github.com/just-the-docs/just-the-docs/issues/982.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice that you filed a bug report! I see that the issue will be fixed in the next release. When we upgrade concrete change should we make instead? (Sorry for the n00b question, I know little about this stuff.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, this will continue to work. When that bug gets fixed, we can adhere to the official/recommended approach of creating a custom scheme and overriding $nav-width s.t. that param gets used throughout the rest of the styling.

See https://just-the-docs.github.io/just-the-docs/docs/customization/#custom-schemes

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check. Didn't fully grok that page yet, but pushed a commit with a proposal :)

Comment on lines 1 to 19
{
"name": "",
"short_name": "",
"icons": [
{
"src": "/assets/images/android-chrome-192x192.png",
"sizes": "192x192",
"type": "image/png"
},
{
"src": "/assets/images/android-chrome-512x512.png",
"sizes": "512x512",
"type": "image/png"
}
],
"theme_color": "#ffffff",
"background_color": "#ffffff",
"display": "standalone"
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found this explanation. Excuse my ignorance; some questions:

  • In our case, what is the expected use case?
  • Should we file in the name and short_name?
  • Is this Chrome/Android-specific, or should we select more generic file names?
  • How were the dimensions chosen?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This too was generated using https://realfavicongenerator.net/ (mentioned here https://github.com/PicnicSupermarket/error-prone-support/blob/f62b632fba36c18510b9737f6720bd16c758e386/website/_includes/head_custom.html).

This is used when adding our docs to your homescreen. See https://realfavicongenerator.net/faq#manifest

Your point stands, we should set name and short name.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not want to add a comment at the top, as JSON comments are not widely supported and could break things.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, can't put a comment here.

Given the generic name of both the file and the JSON property (icons), it seems to me can use more generic image file names. (But perhaps I'm missing something; maybe one of the coming days I'll play with https://realfavicongenerator.net/ myself.)

<link rel="icon" type="image/png" sizes="16x16" href="/assets/images/favicon-16x16.png">
<link rel="manifest" href="/assets/images/site.webmanifest">
<link rel="mask-icon" href="/assets/images/safari-pinned-tab.svg" color="#5bbad5">
<link rel="shortcut icon" href="/favicon.ico">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this one is not inside /assets for compatibility with old browers? Even if so: can't we configure Jekyll to put it in the root, without having it in the website root in the Github repo?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, some (older) browsers assume it's in the root. Also, some scrapers make this assumption. See also https://realfavicongenerator.net/faq#why_icons_in_root

If we really don't want to have in the root, we could move it and disable the favicon check for html-proofer (as that also complains about it). However, I'd prefer to keep it in the root, as is common practice for compatibility.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I mean "is there a way to convince Jekyll to put it into the website/_site root, without it being located in website. Googling around perhaps a hook would do it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I'm not sure if that's any better. We're already in website. So you expect the files are reflected on what we're hosting. Putting something in assets/images, but then referring the root here where some webhook or script puts it there, makes development all the more confusing IMHO.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ack, I'll not make a further point of it then.

website/Gemfile Outdated
@@ -0,0 +1,5 @@
source "https://rubygems.org"
gem "github-pages", "~> 227"
gem "rake", "~> 13.0" # Required for "just-the-docs" theme.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we manage just-the-docs in this Gemfile, then we no longer need to specify rake 😄

@japborst
Copy link
Member Author

japborst commented Oct 2, 2022

It seems that github-pages / jekyll-build-pages automatically ships with jekyll-remote-theme, which was introduce to use themes on GitHub that did not have a nice gem provided https://www.siteleaf.com/blog/remote-themes/

Whilst specifying the gem works locally, the build - however - doesn't actually run bundle install so it fails the build when we're using a local theme.

That leads two options:

  1. Setup ruby, bundler, and run the install manually
  2. Pin the remote theme for a reproducable build

I've now done the latter, as that drastically simplifies the build setup. As we're pinning the version and the latest is an RC, we should keep an eye out for the final v4 release.

@japborst
Copy link
Member Author

japborst commented Oct 3, 2022

Discussed offline with @Stephan202.

Pinning the version is okay for now, but we should investigate a 100% reproducible build s.t. the setup in GHA and locally are 1:1 the same. This is not just for the theme, but for everything (jekyll, html-proofer, etc.)

Copy link
Member

@rickie rickie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a commit.

Caught up on all the discussions, changes LGTM.

@maxsumrall Do you want to finish your review still 😄 ?

@maxsumrall
Copy link
Member

Added a commit.

Caught up on all the discussions, changes LGTM.

@maxsumrall Do you want to finish your review still 😄 ?

Nope, just had the comment, but seems like a lot of effort to get that link to work.

@@ -0,0 +1,5 @@
source "https://rubygems.org"
gem "github-pages", "227"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also fix the Ruby version used? See https://bundler.io/guides/gemfile_ruby.html#specifying-a-ruby-version.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would like to make part of the larger initiative, see #253 (comment)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I didn't read all of the comments so was just a drive-by comment. SGTM 👍

Copy link
Member

@Stephan202 Stephan202 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added one more commit. Some of the filenames suggested by realfavicongenerator.net are still surprising to me, but let's roll with it.

Slightly tweaked the suggested commit message.

Major milestone 💪

@@ -0,0 +1,34 @@
#!/usr/bin/env bash
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll push some suggestions for this file. (Not relying on the side-effect of cd, addressing shellcheck output, etc.)

@japborst
Copy link
Member Author

japborst commented Oct 4, 2022

Yep, favicons are a mess 🙄 Just look at the list of "Why so many files?" at https://realfavicongenerator.net/faq.

Thanks for the last tweaks @Stephan202 🙏

@japborst japborst changed the title Bootstrap documentation website Set up documentation website generation and deployment Oct 4, 2022
@japborst japborst merged commit 5ca95eb into master Oct 4, 2022
@japborst japborst deleted the sschroevers/deploy-to-github-pages branch October 4, 2022 07:08
@japborst
Copy link
Member Author

japborst commented Oct 4, 2022

ps. before merging I verified that generate-docs.sh also runs as expected on a MacOS machine (as it was authored on a Linux machine).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

6 participants