Now that we are really close to switching over https://git-scm.com/ from
the Rails app to the Hugo/Pagefind-generated static site, it is time to
stop assuming that it is the former.
Indeed, I have just changed the `deploy` workflow to ensure that the
site works as expected when being deployed as `http://git-scm.com/`.
So let's just change the `playwright` workflow to have another input
that specifies whether the person triggering that workflow expects the
URL to resolve to a Rails app variant of the site or not, and stop
trying to determine that automatically.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
As all building blocks are now in place to run the Playwright tests
in-place, we can run them as part of every Pull Request, to catch
regressions before they enter the official site.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The UI tests are most beneficial when they are run regularly ;-)
For starters, this allows running them in a GitHub workflow that is
triggered manually, offering the user to specify which site to test.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Broken links are quite an annoyance for readers, and at least for links
that point to pages within the same static website, there are tools to
help identify those.
One such tool is called `lychee`. It has already a number of very useful
options and even sports a GitHub Action for easy integration into GitHub
workflows.
To accommodate the migration of https://git-scm.com/ from a Rails App to
a static site generated using Hugo, lychee was taught the trick needed
to support checking links in a static website with "pretty URLs" (i.e.
URLs lacking the `.html` file extension even though the files backing
those URLs do have that extension, something GitHub Pages supports).
With this mode, the automation that deploys https://git-scm.com/ can
make use of that link checker.
Seeing as broken links often originate from repositories outside of
https://github.com/git/git-scm.com's control, rather than failing
deployment when broken links are detected, let's follow the "best
effort" strategy and open a ticket about the broken links while still
letting the deployments complete.
In PR builds, links are also checked, and broken links will let them
fail.
While it was tempting to use a convenient GitHub Action like
`peter-evans/create-issue-from-file` to open the GitHub issue, there is
no readily-available Action to either open, update, or update & close
such a ticket, depending on the outcome of the link check and whether
such a ticket exists already and is open. Therefore, I opted for a more
verbose (and much more powerful) `actions/github-script` step to perform
this part of the job.
Based-on-feedback-by: Todd Zullinger <tmz@pobox.com>
Helped-by: Matthias Endler <matthias@endler.dev>
Helped-by: Thomas Zahner <thomas.zahner@protonmail.ch>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
After taking care of the English manual pages, let's also have a
scheduled workflow that takes care of updating the translated manual
pages.
Just like the scheduled workflow that takes care of the original,
English manual pages, here we also need a flag to toggle complete
rebuilds in case the script, the style sheets, or the layouts changed.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When merging PRs, or pushing changes directly, we will want to deploy
the result to GitHub Pages. That's this new workflow's job.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Sometimes a bug is found in the way the manual pages are built,
requiring a change e.g. in the `update-docs.rb` script or in the
corresponding style sheets.
In such a case, the manual pages have to be rebuilt from scratch, even
if they exist already.
This commit introduces the `force-rebuild` flag to do this.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Whenever a new Git version is released, we will want git-scm.com to be
updated automatically.
To this end, add a scheduled workflow that does precisely that. In case
someone gets too impatient to wait for the daily check, there's also a
`workflow_dispatch` trigger.
Note: It would be tempting to use a partial clone of git.git for this,
but that would cause many, many round-trips (each time a blob is
requested), especially when force-rebuilding all versions of all manual
pages (which will be added in a later commit). So let's not.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Even when everything is marked up to date, it is sometimes necessary to
rebuild the books e.g. due to style/layout changes.
With this here commit, that is possible by toggling the `force-rebuild`
flag of the `workflow_dispatch` trigger.
This commit is best viewed with `git show -w`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This workflow has a `workflow_dispatch` trigger to allow for manually
starting this workflow directly after, say, a Git for Windows version
was released.
Signed-off-by: Johannes Schindelin <johannesc.schindelin@gmx.de>
With this commit, the SHAs corresponding to the various repositories
containing the ProGit Book and its translations are stored in a
sparse-checkout'able directory.
This information is then used by a scheduled workflow to determine what
needs to be updated (if anything) and then performing that task.
When GitHub workflows push new changes, they cannot trigger other GitHub
workflows (to avoid infinite loops). Therefore, this new GitHub workflow
not only synchronizes the books, but also builds the site and deploys
it.
Note: The code to build the site and to deploy it is provided in a
custom Action, to make it reusable. It will come in handy over the next
commits, where other GitHub workflows are added that likewise need
to synchronize changes that desire a site rebuild & deployment.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
To make it work both in the primary repository's GitHub Pages as well as
in the forks' GitHub Pages, we really need the URLs to be specified as
relative ones. Make sure that this is the case in the CI builds.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We definitely want the search results for, say, "commit" to show the
manual page of that command first.
This took quite a bit of work to accomplish, including a change to
Pagefind itself (https://github.com/CloudCannon/pagefind/pull/534) as
well as some extensive fiddling with the ranking weights (including, I
kid you not, running a Powell's optimization of the weights).
To ensure that the results are shown in the desired order, let's add an
explicit check for that in the PR builds.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We now use Pagefind (https://pagefind.app/) to implement a client-side,
Javascript-based search.
For now, the "live search" is not implemented, only the full search
results (i.e. what happens after pressing the Enter key in the search
box).
Pagefind is maintained actively, integrates well with Hugo, and is very
fast, in particular because in contrast to most other client-side search
solutions the search index is not one single, gigantic file, but is
downloaded in chunks, as needed.
Alternatives to Pagefind I considered were:
- `lunr.js` (https://lunrjs.com/), one of the oldest client-side search
solutions. Indeed, the first iteration of client-side search that I
implemented was using `lunr.js`.
Sadly, lunr.js seems to be no longer actively maintained. And it comes
at the price of one big search index file. Even if a pre-processed
search index is used, even restricting to English and only to the
newest versions of the manual pages, it weighs in with 3 megabytes,
which takes a prohibitively long time load while the user is waiting
for search results.
- https://github.com/jameslittle230/stork
As of time of writing, this seems to have become unmaintained.
- https://github.com/tinysearch/tinysearch
Seems to be limited to whole-word search.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Since this is now a static site built with Hugo, let's switch the CI
builds to do exactly that.
While at it, update the `actions/checkout` version.
Technically, we do not need to upload the result, but it makes for
easier debugging.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We trigger CI on both "push" and "pull_request". The latter is necessary
to get CI results for people opening a PR from their own fork. The
former is not strictly necessary, but it's nice to get the PR running as
soon as we know about the commits, so that it's often finished by the
time you've finished opening up the PR.
But this does result in duplicate runs for branches pushed directly into
the repo: once when the branch is pushed, and once when the PR is
opened. We could get around this by skipping the workflow when we've
already got the same job running, but that's more complicated. Let's
just drop the "push" trigger. The CI here is pretty fast anyway (at
least once the bundler bits are all cached, but that should be the case
for any PR that doesn't update gems).
This has some security fixes, though none that should impact us. Mostly
I want to make sure the bumping process works with CI (it would be nice
if we could read the .ruby-version or Gemfile from the CI code; I think
it's possible but non-trivial).
Since travis-ci.org has shut down, we no longer have functioning CI for
pull requests. Let's translate this to a GitHub Actions workflow.
Our set of actual tests is still pretty lousy, but this at least
gets our basic sanity checks running again.
Johannes Schindelin
HonkingGoose
Jeff King