Conversation
|
oof. so if we deploy in advance they don't get built into the static output? |
|
I haven't groked the issue completely, but does timezone need to be factored in? |
|
I wonder if it could also be an option switching the flag that disables this behaviour, and live with blogs being published before their nominal post time. |
SamBarker
force-pushed
the
feat/future-deploy-warning
branch
from
5b1ad40 to
5768878
Compare
TZ is already accounted for, in that its included in the post timestamp, however the file I copied to write the post used UTC, and while I updated the date I didn't change the time so the post merged but didn't go live. It would have done if I had set the TZ to +1300. But you did make me realise we weren't considering the timezone when checking dates.
I think its a useful property to be able to merge in advance of publication. It just needs an extra action run post fact. |
When a push to main includes future-dated posts, the deploy workflow now adds a warning to the GitHub Actions job summary listing the affected posts and their publish dates, with a reminder to re-run the workflow manually on the publish date. Both the filename date and front matter date are checked, using whichever is later. Assisted-by: Claude Sonnet 4.6 <noreply@anthropic.com> Signed-off-by: Sam Barker <sam@quadrocket.co.uk>
Adds a PR check that fails if any post in _posts/ has a filename date that doesn't match the date in its front matter, catching accidental mismatches early. Assisted-by: Claude Sonnet 4.6 <noreply@anthropic.com> Signed-off-by: Sam Barker <sam@quadrocket.co.uk>
Rather than requiring an exact match, only fail if the front matter date is older than the filename date, which is the case that would cause Jekyll to publish later than expected. Assisted-by: Claude Sonnet 4.6 <noreply@anthropic.com> Signed-off-by: Sam Barker <sam@quadrocket.co.uk>
Signed-off-by: Sam Barker <sam@quadrocket.co.uk>
Previously the check only extracted YYYY-MM-DD from the front matter date, silently discarding any time and timezone offset. This caused false positives for NZ-timezone posts (e.g. "2026-03-05 00:00:00 +1300" is 2026-03-04 in UTC, but the check treated it as March 5) and false negatives for posts with negative UTC offsets. Now the full front matter date value is passed to GNU date with -u -d to get the correct UTC date, matching Jekyll's own behaviour. Assisted-by: Claude Sonnet 4.6 <noreply@anthropic.com> Signed-off-by: Sam Barker <sam@quadrocket.co.uk>
SamBarker
force-pushed
the
feat/future-deploy-warning
branch
from
a585e85 to
3c154ec
Compare
|
You can see the checks failing on my fork |
3 participants
Jekyll posts have a date. Jekyll has a configurable behaviour about whether to include future dated posts, which defaults to false. This means future-dated posts are excluded during static generation. Our site builds are only driven by merging PRs to this repository. So if we accidentally future-date a Release Blog, then it can happen that on merge it is not made visible and will not be until another PR is merged after the post date. This is not what we are intending when we hit the Merge button.
This PR adds a couple of checks.