chore: check-html-links
This commit is contained in:
Frank Taillandier
parent
872132e725
commit
e0e856f216
|
|
@ -76,7 +76,7 @@ site:
|
|||
Contains the url of your site as it is configured in the <code>_config.yml</code>.
|
||||
For example, if you have <code>url: http://mysite.com</code> in your configuration file,
|
||||
then it will be accessible in Liquid as <code>site.url</code>. For the development
|
||||
environment there is <a href="/news/#3-siteurl-is-set-by-the-development-server">an
|
||||
environment there is <a href="/news/2016/10/06/jekyll-3-3-is-here/#3-siteurl-is-set-by-the-development-server">an
|
||||
exception</a>, if you are running <code>jekyll serve</code> in a development environment
|
||||
<code>site.url</code> will be set to the value of <code>host</code>, <code>port</code>,
|
||||
and SSL-related options. This defaults to <code>url: http://localhost:4000</code>.
|
||||
|
|
|
|||
|
|
@ -16,8 +16,7 @@ If you're looking for support for Jekyll, there are a lot of options:
|
|||
|
||||
* Read the [Jekyll Documentation]({{ '/docs/' | relative_url }})
|
||||
* If you have a question about using Jekyll, start a discussion on the [Jekyll Forum](https://talk.jekyllrb.com/) or [StackOverflow](https://stackoverflow.com/questions/tagged/jekyll)
|
||||
* Chat with Jekyllers — Join our [Gitter channel](https://gitter.im/jekyll/jekyll) or our [IRC channel on Freenode](irc:irc.freenode.net/jekyll)
|
||||
|
||||
* Chat with Jekyllers — Join our [Gitter channel](https://gitter.im/jekyll/jekyll) or our [IRC channel on Freenode](irc://irc.freenode.net/jekyll
|
||||
There are a bunch of helpful community members on these services who are willing to point you in the right direction.
|
||||
|
||||
**Reminder: Jekyll's issue tracker is not a support forum.**
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ defaults:
|
|||
during automatic regeneration are not loaded until the next execution.
|
||||
</p>
|
||||
<p>
|
||||
Note <a href="{{ '/docs/datafiles' | relative_url }}">Data Files</a> are included and reloaded during automatic regeneration.
|
||||
Note <a href="{{ '/docs/datafiles/' | relative_url }}">Data Files</a> are included and reloaded during automatic regeneration.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,6 @@ When building a Jekyll site with GitHub Pages, the standard flow is restricted f
|
|||
and to make it simpler to get a site setup. For more control over the build and still host the site
|
||||
with GitHub Pages you can use GitHub Actions.
|
||||
|
||||
|
||||
## Advantages of using Actions
|
||||
|
||||
### Control over gemset
|
||||
|
|
@ -25,16 +24,15 @@ with GitHub Pages you can use GitHub Actions.
|
|||
- **Logging** --- The build log is visible and can be tweaked to be verbose, so it is much easier to
|
||||
debug errors using Actions.
|
||||
|
||||
|
||||
## Workspace setup
|
||||
|
||||
The first and foremost requirement is a Jekyll project hosted at GitHub. Choose an existing Jekyll
|
||||
project or follow the [quickstart]({{ '/docs' | relative_url }}) and push the repository to GitHub
|
||||
project or follow the [quickstart]({{ '/docs/' | relative_url }}) and push the repository to GitHub
|
||||
if it is not hosted there already.
|
||||
|
||||
We're only going to cover builds from the `master` branch in this page. Therefore, ensure that you
|
||||
are working on the `master` branch. If necessary, you may create it based on your default branch.
|
||||
When the Action builds your site, the contents of the *destination* directory will be automatically
|
||||
When the Action builds your site, the contents of the _destination_ directory will be automatically
|
||||
pushed to the `gh-pages` branch with a commit, ready to be used for serving.
|
||||
|
||||
{: .note .warning}
|
||||
|
|
@ -53,6 +51,7 @@ title: "Jekyll Actions Demo"
|
|||
```
|
||||
|
||||
{% raw %}
|
||||
|
||||
```liquid
|
||||
---
|
||||
---
|
||||
|
|
@ -64,8 +63,8 @@ Welcome to My Home Page
|
|||
- Original date - {{ date }}
|
||||
- With timeago filter - {{ date | timeago }}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
{% endraw %}
|
||||
|
||||
```ruby
|
||||
# Gemfile
|
||||
|
|
@ -100,6 +99,7 @@ Create a **workflow file**, say `github-pages.yml`, using either the GitHub inte
|
|||
a YAML file to the workflow directory path manually. The base contents are:
|
||||
|
||||
{% raw %}
|
||||
|
||||
```yaml
|
||||
name: Build and deploy Jekyll site to GitHub Pages
|
||||
|
||||
|
|
@ -117,6 +117,7 @@ jobs:
|
|||
env:
|
||||
JEKYLL_PAT: ${{ secrets.JEKYLL_PAT }}
|
||||
```
|
||||
|
||||
{% endraw %}
|
||||
|
||||
The above workflow can be explained as the following:
|
||||
|
|
@ -128,7 +129,7 @@ The above workflow can be explained as the following:
|
|||
- We specify our selected **action** and **version number** using `helaili/jekyll-action@2.0.5`.
|
||||
This handles the build and deploy.
|
||||
- We set a reference to a secret **environment variable** for the action to use. The `JEKYLL_PAT`
|
||||
is a *Personal Access Token* and is detailed in the next section.
|
||||
is a _Personal Access Token_ and is detailed in the next section.
|
||||
|
||||
Instead of using the **on.push** condition, you could trigger your build on a **schedule** by
|
||||
using the [on.schedule] parameter. For example, here we build daily at midnight by specifying
|
||||
|
|
@ -137,7 +138,7 @@ using the [on.schedule] parameter. For example, here we build daily at midnight
|
|||
```yaml
|
||||
on:
|
||||
schedule:
|
||||
- cron: '0 0 * * *'
|
||||
- cron: "0 0 * * *"
|
||||
```
|
||||
|
||||
Note that this string must be quoted to prevent the asterisks from being evaluated incorrectly.
|
||||
|
|
@ -145,7 +146,6 @@ Note that this string must be quoted to prevent the asterisks from being evaluat
|
|||
[on.schedule]: https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#onschedule
|
||||
[crontab guru]: https://crontab.guru/
|
||||
|
||||
|
||||
### Providing permissions
|
||||
|
||||
The action needs permissions to push to your `gh-pages` branch. So you need to create a GitHub
|
||||
|
|
@ -159,7 +159,7 @@ build using _Secrets_:
|
|||
to commit to the `gh-pages` branch.
|
||||
3. **Copy** the token value.
|
||||
4. Go to your repository's **Settings** and then the **Secrets** tab.
|
||||
5. **Create** a token named `JEKYLL_PAT` (*important*). Give it a value using the value copied
|
||||
5. **Create** a token named `JEKYLL_PAT` (_important_). Give it a value using the value copied
|
||||
above.
|
||||
|
||||
### Build and deploy
|
||||
|
|
@ -171,11 +171,11 @@ To watch the progress and see any build errors, check on the build **status** us
|
|||
following approaches:
|
||||
|
||||
- **View by commit**
|
||||
- Go to the repository level view in GitHub. Under the most recent commit (near the top) you’ll
|
||||
see a **status symbol** next to the commit message as a tick or _X_. Hover over it and click
|
||||
the **details** link.
|
||||
- Go to the repository level view in GitHub. Under the most recent commit (near the top) you’ll
|
||||
see a **status symbol** next to the commit message as a tick or _X_. Hover over it and click
|
||||
the **details** link.
|
||||
- **Actions tab**
|
||||
- Go to the repository's Actions tab. Click on the `jekyll` workflow tab.
|
||||
- Go to the repository's Actions tab. Click on the `jekyll` workflow tab.
|
||||
|
||||
If all goes well, all steps will be green and the built assets will now exist on the `gh-pages`
|
||||
branch.
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ You want to maintain Jekyll? Use it often. Do weird things with it. Do normal th
|
|||
|
||||
## 2. Help Triage Issues
|
||||
|
||||
Watch the repository you're interested in. Join [an Affinity Team](https://teams.jekyllrb.com) and receive mentions regarding a particular interest area of the project. When you receive a notification for an issue that has not been triaged by a maintainer, dive in. Can you reproduce the issue? Can you determine the fix? [More tips on Triaging an Issue in our maintainer guide](../triaging-an-issue). Every maintainer loves an issue that is resolved before they get to it. :smiley:
|
||||
Watch the repository you're interested in. Join [an Affinity Team](https://teams.jekyllrb.com) and receive mentions regarding a particular interest area of the project. When you receive a notification for an issue that has not been triaged by a maintainer, dive in. Can you reproduce the issue? Can you determine the fix? [More tips on Triaging an Issue in our maintainer guide](../triaging-an-issue/). Every maintainer loves an issue that is resolved before they get to it. :smiley:
|
||||
|
||||
## 3. Write Documentation
|
||||
|
||||
|
|
@ -25,7 +25,7 @@ As a maintainer, you will be reviewing pull requests which update code. You shou
|
|||
|
||||
## 5. Review Pull Requests
|
||||
|
||||
Start by reviewing one pull request a week. Leave detailed comments and [follow our guide for reviewing pull requests](../reviewing-a-pull-request).
|
||||
Start by reviewing one pull request a week. Leave detailed comments and [follow our guide for reviewing pull requests](../reviewing-a-pull-request/).
|
||||
|
||||
## 6. Ask!
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ title: "Merging a Pull Request"
|
|||
|
||||
All pull requests should be subject to code review. Code review is a [foundational value](https://blog.fullstory.com/what-we-learned-from-google-code-reviews-arent-just-for-catching-bugs/) of good engineering teams. Besides providing validation of correctness, it promotes a sense of community and gives other maintainers understanding of all parts of the code base. In short, code review is crucial to a healthy open source project.
|
||||
|
||||
**Read our guide for [Reviewing a pull request](../reviewing-a-pull-request) before merging.** Notably, the change must have tests if for code, and at least two maintainers must give it an OK.
|
||||
**Read our guide for [Reviewing a pull request](../reviewing-a-pull-request/) before merging.** Notably, the change must have tests if for code, and at least two maintainers must give it an OK.
|
||||
|
||||
## Merging
|
||||
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ If you have a lot of pages, you can organize them into subfolders. The same subf
|
|||
|
||||
## Changing the output URL
|
||||
|
||||
You might want to have a particular folder structure for your source files that changes for the built site. With [permalinks](/docs/permalinks) you have full control of the output URL.
|
||||
You might want to have a particular folder structure for your source files that changes for the built site. With [permalinks](/docs/permalinks/) you have full control of the output URL.
|
||||
|
||||
## Excerpts for pages
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ language which has three main components:
|
|||
|
||||
## Objects
|
||||
|
||||
Objects tell Liquid to output predefined [variables](../../variables) as content on a page. Use double curly braces for objects: {% raw %}`{{`{% endraw %} and {% raw %}`}}`{% endraw %}.
|
||||
Objects tell Liquid to output predefined [variables](../../variables/) as content on a page. Use double curly braces for objects: {% raw %}`{{`{% endraw %} and {% raw %}`}}`{% endraw %}.
|
||||
|
||||
For example, {% raw %}`{{ page.title }}`{% endraw %} displays the `page.title` variable.
|
||||
|
||||
|
|
@ -52,11 +52,11 @@ For example:
|
|||
|
||||
This displays `Hi` instead of `hi`.
|
||||
|
||||
Learn more about the filters available in Jekyll [here](/docs/liquid/filters/).
|
||||
[Learn more about the filters](/docs/liquid/filters/) available.
|
||||
|
||||
## Use Liquid
|
||||
|
||||
Now, use Liquid to make your `Hello World!` text from [Setup](../01-setup) lowercase:
|
||||
Now, use Liquid to make your `Hello World!` text from [Setup](../01-setup/) lowercase:
|
||||
|
||||
{% raw %}
|
||||
```liquid
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ If you're looking for support for Jekyll, there are a lot of options:
|
|||
|
||||
* Read [Jekyll Documentation](https://jekyllrb.com/docs/home/)
|
||||
* If you have a question about using Jekyll, start a discussion on [Jekyll Forum](https://talk.jekyllrb.com/) or [StackOverflow](https://stackoverflow.com/questions/tagged/jekyll)
|
||||
* Chat with Jekyllers — Join [our Gitter channel](https://gitter.im/jekyll/jekyll) or [our IRC channel on Freenode](irc:irc.freenode.net/jekyll)
|
||||
* Chat with Jekyllers — Join [our Gitter channel](https://gitter.im/jekyll/jekyll) or [our IRC channel on Freenode](irc://irc.freenode.net/jekyll)
|
||||
|
||||
There are a bunch of helpful community members on these services that should be willing to point you in the right direction.
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Hey, folks! Bunch of bug fixes here. Notables:
|
|||
* All hooks should now be properly registered & documented
|
||||
|
||||
And a bunch more changes which you can see over in the
|
||||
[changelog](/docs/history).
|
||||
[changelog](/docs/history/).
|
||||
|
||||
Thanks to the 17 developers who contributed code and documentation to this
|
||||
patch release: Alfred Xing, Christian Trosell, Jordan Thornquest, Jordon
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ No matter which Code of Conduct you pick, the most important thing is to actuall
|
|||
|
||||
The problem that puts people off the most is incomplete or missing documentation, as revealed through GitHub's [open source survey](http://opensourcesurvey.org/2017). A very popular myth in programming is that good code explains itself, which might be true, but only for the person writing it. It's important, especially once you put your project out there for the world to see, to document not only your code, but also the process by which you maintain it. Otherwise, it's going to be extremely hard for newcomers to even figure out where to begin contributing to your project.
|
||||
|
||||
Jekyll has [an entire section of its docs](/docs/contributing) dedicated to information on how to contribute for this very reason. Every documentation page has a link to directly edit and improve it on GitHub. It's also important to realize that not all contributions are code. It can be documentation, it can be reviewing pull requests, but it can also just be weighing into issues, and all of this should be recognized in the same way. At Jekyll, out of 397 total merged pull requests in the last year, __204__ were documentation pull requests!
|
||||
Jekyll has [an entire section of its docs](/docs/contributing/) dedicated to information on how to contribute for this very reason. Every documentation page has a link to directly edit and improve it on GitHub. It's also important to realize that not all contributions are code. It can be documentation, it can be reviewing pull requests, but it can also just be weighing into issues, and all of this should be recognized in the same way. At Jekyll, out of 397 total merged pull requests in the last year, __204__ were documentation pull requests!
|
||||
|
||||
## Create newcomer-friendly issues
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ We're happy to release a new minor for the new year.
|
|||
Here are a few of the latest additions from our contributors:
|
||||
|
||||
* LiveReload is available as an option during development: with `jekyll serve --livereload` no more manual page refresh. A big thanks to @awood for this feature and to @andreyvit, LiveReload author.
|
||||
* New `collections_dir` configuration option allows you to store all your [collections](/docs/collections) in a single folder. Your source root folder should now look cleaner :sparkles: .
|
||||
* New `collections_dir` configuration option allows you to store all your [collections](/docs/collections/) in a single folder. Your source root folder should now look cleaner :sparkles: .
|
||||
* If you're using a [gem-based theme](/docs/themes/) in coordination with the `--incremental` option, you should notice some significant speed during the regeneration process, we did see build time went down **from 12s to 2s** with @mmistakes [minimal-mistakes theme](https://github.com/mmistakes/minimal-mistakes) during our tests.
|
||||
* Jekyll will now check to determine whether host machine has internet connection.
|
||||
* A new `latin` option is available to better [handle URLs slugs](/docs/liquid/filters/#options-for-the-slugify-filter).
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ author: parkr
|
|||
categories: [team]
|
||||
---
|
||||
|
||||
Jekyll has a new Lead Developer: [Olivia](https://liv.cat/)!
|
||||
Jekyll has a new Lead Developer: Olivia!
|
||||
|
||||
After over 5 years of leading Jekyll, many releases from 0.12.1 to 3.6.0, and
|
||||
countless conversations in GitHub Issues, Pull Requests, Jekyll Talk, and
|
||||
|
|
@ -19,8 +19,8 @@ community lead. Olivia joined the Jekyll Core Team with experience in the
|
|||
Node.js community, both online and as a volunteer organizer with JSConf EU.
|
||||
|
||||
In my conversations with Olivia, it is clear that Jekyll's vision of
|
||||
simplicity for the user ([no magic!](/philosophy#1-no-magic)) and letting
|
||||
users' [content be king](/philosophy#3-content-is-king) will remain a top
|
||||
simplicity for the user ([no magic!](/philosophy/#1-no-magic)) and letting
|
||||
users' [content be king](/philosophy/#3-content-is-king) will remain a top
|
||||
priority. In just the last few weeks as the transition has been occurring,
|
||||
we have seen some incredible work on performance that will make future
|
||||
versions of Jekyll work better at scale. She will be prioritizing work on
|
||||
|
|
|
|||
|
|
@ -38,8 +38,6 @@ of time taken during various stages of the *build process*.
|
|||
* Jekyll's development server now supports certificates based on Elliptic-curve cryptography.
|
||||
|
||||
For the interest of plugin authors:
|
||||
* `Jekyll::Page` now uses a Liquid Drop to expose attributes for Liquid templates. However, its subclasses will continue
|
||||
using the legacy `ATTRIBUTES_FOR_LIQUID` hash by default. More details in the [associated documentation][page-drop-docs]
|
||||
* Excerpts won't be generated for `Jekyll::Page` subclasses automatically unless such instances have an `excerpt` key in
|
||||
their `data` hash.
|
||||
|
||||
|
|
@ -53,9 +51,6 @@ released gem, please remove `|_config\.yml` from the regular expression in the g
|
|||
[{{ filter_slug }}-filter]: {{ filter_slug | prepend: '/docs/liquid/filters/#' | relative_url }}
|
||||
{% endfor %}
|
||||
|
||||
[page-drop-docs]: {{ 'docs/pages/#for-plugin-developers' | relative_url }}
|
||||
|
||||
|
||||
### Have questions?
|
||||
|
||||
Please reach out on our [community forum](https://talk.jekyllrb.com)
|
||||
|
|
|
|||
|
|
@ -116,7 +116,7 @@ Open `default.html` into your browser locally to ensure the site looks and behav
|
|||
|
||||
For example, if the paths were relative on the site you copied, you'll need to either download the same assets into your Jekyll site or use absolute paths to the same assets in the cloud. (Syntax such as `src="//` requires a prefix such as `src="http://` to work in your local browser.)
|
||||
|
||||
Jekyll provides some [filters](/docs/liquid/filters) to prepend a site URL before path. For example, you could preface your stylesheet like this:
|
||||
Jekyll provides some [filters](/docs/liquid/filters/) to prepend a site URL before path. For example, you could preface your stylesheet like this:
|
||||
|
||||
{% raw %}
|
||||
```liquid
|
||||
|
|
|
|||
Loading…
Reference in New Issue