You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+71Lines changed: 71 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -26,6 +26,20 @@ $ git sparse-checkout set layouts content static assets hugo.yml data script
26
26
$ git reset --hard
27
27
```
28
28
29
+
> [!NOTE]
30
+
> On Windows, if you cannot use [Windows Subsystem for Linux (WSL)](https://learn.microsoft.com/en-us/windows/wsl/) for some reason, you will be unable to build the site as-is. The reason is that some URLs of the git-scm.com site contain question marks, for historical reasons. These question marks are obviously encoded as `%3F` in the URLs, but the way Hugo works, they are literal question marks in the filenames of the corresponding files. Such filenames are accommodated easily by Linux filesystems, but on Windows, filenames containing question marks are forbidden. For that reason, to build the site on Windows, the following command needs to be run (assuming a Bash, as the rest of this document):
> This edits the affected files' `url` front-matter attributes to avoid writing those files containing question marks. Obviously, the result does not support the backwards-compatible URLs that contain URL-encoded question marks.
42
+
29
43
> [!NOTE]
30
44
> If you _already_ have a full clone and wish to accelerate development by focusing only on a small subset of the pages, you may want to run the `git sparse-checkout set [...]` command mentioned above.
31
45
@@ -93,12 +107,66 @@ $ HUGO_UGLYURLS=false hugo
93
107
$ npx -y pagefind --site public --serve
94
108
```
95
109
110
+
If you want to make sure that the same Pagefind version is used as when the site is deployed, use this command:
111
+
112
+
```console
113
+
$ npx -y pagefind@$(sed -n 's/^ *pagefind_version: //p'<./hugo.yml) --site public
114
+
```
115
+
96
116
Note that running Pagefind will make the process about 7 times slower, and the site will not be re-rendered and live-reloaded in the browser when you change files in`content/` (unlike with `hugo serve -w`).
97
117
98
118
## Running the test suite
99
119
100
120
Believe it or not, https://git-scm.com/ has its own test suite. It uses [Playwright](https://playwright.dev/) to perform a couple of tests that verify that the site "looks right". These tests live in`tests/` and are configured via `playwright.config.js`.
101
121
122
+
> [!NOTE]
123
+
> Building the site, letting Pagefind generate the search index, and then running the test suite can be quite time consuming. To accelerate the development cycle, it is _highly_ recommended to use a sparse checkout instead of a full clone. The minimal sparse checkout required to run the test suite can be configured like this:
124
+
>
125
+
>```console
126
+
> $ MSYS_NO_PATHCONV=1 git config set --worktree core.sparseCheckoutCone false
127
+
> $ git config set --worktree core.sparseCheckout true
> On Windows, unless you're doing all this in WSL, do not forget to run the commands mentioned earlier to edit the `url` front-matter attributes that contain question marks!
162
+
>
163
+
> The site can then be built quickly via these commands:
To run these tests in your local setup, you need a working node.js installation. After that, you need to install Playwright:
103
171
104
172
```console
@@ -121,6 +189,9 @@ $ PLAYWRIGHT_TEST_URL='http://localhost:5000/' npx playwright test --project=fir
121
189
122
190
For more fine-grained testing, you can pass `-g <regex>` to run only the matching test cases.
123
191
192
+
> [!NOTE]
193
+
> When running the test suite on platforms other than Linux, the first run will "fail"in the `dark mode`test case. That is expected! This testcase relies on previously-generated screenshots that are stored in`tests/git-scm.spec.js-snapshots/`, and for bandwidth reasons only the Linux ones are committed in the Git repository (because they are required to run the PR/CI builds). The first run will store those screenshots so that subsequent runs of this test case will succeed, though.
0 commit comments