Add PR preview in CI for easier review #19
Merged
Merged
Conversation
|
b950903 to
3842f44
Compare
Contributor
|
LGTM Approved! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
So this PR includes a generated preview of the site that is built based on the PR. That way it'll be easier to review in the future. It only works from branches PRs, if the PR comes from a fork, it skips the workflow because it's not possible to run it due to security (the GHA does not work, so to avoid the error we skip it directly.
A maintainer will have to run from local. I added this into the CONTRIBUTING.md.
For some reason (I think it might be a DNS thing, but I'm not sure). Even though the action creates a
httpspreview link, when opening, it shows ashttpand it says not secure, it's unclear why to me.Note: There were some hard-coded paths, that were breaking being able to render well the preview. Claude suggested using relative paths, and that worked.
Some of the changes needed to make this work:
Every hardcoded /path is now wrapped with {{ '...' | relative_url }}, so they'll respect baseurl in both production and previews. The data file paths in
_data/event_highlights.yml are handled at the template level (the {{ event.image | relative_url }} fix in homepage.html), so they don't need to change.
{{ '...' | relative_url }}
In Jekyll's Liquid templating language:
So {{ '/blog/' | relative_url }} works like this:
For the data file case, {{ event.image | relative_url }} does the same thing but reads the path from a variable instead of a string literal.