Skip to content
This repository has been archived by the owner on Aug 21, 2024. It is now read-only.

Dates work locally, but not when served with AWS #69

Open
smugclimber opened this issue Apr 10, 2019 · 14 comments
Open

Dates work locally, but not when served with AWS #69

smugclimber opened this issue Apr 10, 2019 · 14 comments

Comments

@smugclimber
Copy link

Using this code in one of my include files
{{ page.last_modified_at | date: '%B %d, %Y' }}
to show the user the last time the article was updated. The jekyll-last-modified-at plugin works like a charm locally and shows the file mod date in my page html. However, when I push it up to the AWS server, the live site marks every article with January 01, 1970.

Any ideas how to remedy this? Think it's a bug or part of my build setup?

Project Specs:
Jekyll 3.8.5
Bundler 1.16.0
Gem 2.6.11
jekyll-last-modified-at 1.1.0

@smugclimber smugclimber changed the title Dates works locally, but not when served with AWS Dates work locally, but not when served with AWS Apr 10, 2019
@EdenKupe
Copy link

EdenKupe commented Aug 20, 2019

I'm facing a similar issue on Platform.sh. Works well locally but all dates are the same on the live site, set to the last time any page was updated.

FYI - I've also encountered this issue with other Jekyll plugins so it might be a Jekyll issue instead of a specific one with this plugin.

@bronzdoc
Copy link

bronzdoc commented Sep 18, 2019

Facing the same issue on Heroku

@EdenKupe
Copy link

From what I've been told (sorry, I don't remember where), this is not a bug but a change in how Jekyll works. When you build the site now, Jekyll "touches" all files, essentially modifying them. Haven't been able to find a work-around to this so if anyone has one, let us know!

@lubc
Copy link

lubc commented Dec 9, 2019

In case anyone is interested, here there's a tool to manage outdated articles in Jekyll: https://github.com/marketplace/outdated-article

@prenetic
Copy link

prenetic commented Mar 2, 2022

I know this is an old thread, but I'm running into the same issue on Cloudflare Pages. Locally the dates are rendered correctly (using them for my sitemap), but on Cloudflare it shows the fallback date for all entries, which is the publishing date.

There's a mention in the README.md about fallback value being derived from a file's mtime if the last Git commit date is inaccessible for some reason, so I'm wondering if that might have something to do with this.

@prenetic
Copy link

prenetic commented Mar 6, 2022

I reached out to the folks on the Cloudflare Developers Discord server, and a Cloudflare community member reached out and provided this information:

We checkout the commit (detached head) so there isn't a history. You could get that commits date but not any previous commits date.

@itay1313
Copy link

itay1313 commented Aug 8, 2022

Hey, I'm having the same problem as well :)
Anyone found a workaround for this?

@bewuethr
Copy link

bewuethr commented Nov 26, 2022

I believe this happens when you do a shallow clone or checkout, like what the actions/checkout action does by default. As this plugin looks at the most recent Git commit, and there is only one, every last_modified_at timestamp is going to be equal to that last commit's time.

A workaround, for GitHub Actions, could be to use fetch-depth: 0 to fetch the entire history, but that can be slow.

Edit: actually, not too bad... my page has 388 commits, and the repo clocks in at about 193 MB; checkout isn't any slower with fetch-depth: 0. I guess it depends on your repo history, but if your diffs are mostly adding new things, I believe there isn't a big difference between shallow and deep clones.

@Mohamed3nan
Copy link

try to concatenating git fetch --unshallow && onto the build command

VerzatileDev added a commit to VerzatileDev/Programming_HandBook that referenced this issue Dec 20, 2023
VerzatileDev added a commit to VerzatileDev/Programming_HandBook that referenced this issue Dec 20, 2023
@VerzatileDev
Copy link

I believe this happens when you do a shallow clone or checkout, like what the actions/checkout action does by default. As this plugin looks at the most recent Git commit, and there is only one, every last_modified_at timestamp is going to be equal to that last commit's time.

A workaround, for GitHub Actions, could be to use fetch-depth: 0 to fetch the entire history, but that can be slow.

Edit: actually, not too bad... my page has 388 commits, and the repo clocks in at about 193 MB; checkout isn't any slower with fetch-depth: 0. I guess it depends on your repo history, but if your diffs are mostly adding new things, I believe there isn't a big difference between shallow and deep clones.

Thank you for the work around, Did not even think of using "fetch-depth" to be quite honest, saved me another hour of headache.

@omarcostahamido
Copy link

@VerzatileDev @bewuethr
I reckon you add that line in the .github/workflows/jekyll.yml file, correct?
Where exactly do you add it?
is it like this?

jobs:
  # Build job
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          fetch-depth: 0

@VerzatileDev
Copy link

@VerzatileDev @bewuethr I reckon you add that line in the .github/workflows/jekyll.yml file, correct? Where exactly do you add it? is it like this?

jobs:
  # Build job
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          fetch-depth: 0

@omarcostahamido I forgot how I did it all, but seeing my pull requests and issue as the following: VerzatileDevOrg/Programming_HandBook#40 and VerzatileDevOrg/Programming_HandBook#51 might be a good place to start.

fetch-depth: 0 should be what gets the entire history or the repository, so that would be for every commit made in it, from that this is where the " Last Modified " comes in. You can then follow my comments and resources there

Good luck!

@bewuethr
Copy link

bewuethr commented Mar 17, 2024

@VerzatileDev @bewuethr I reckon you add that line in the .github/workflows/jekyll.yml file, correct? Where exactly do you add it? is it like this?

jobs:
  # Build job
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          fetch-depth: 0

You have to do the deep clone in the same job as the jekyll build step. Here's how I do it for a Jekyll website that I maintain:

jobs:
  build:
    name: Build page
    runs-on: ubuntu-22.04
    permissions:
      contents: read
    env:
      RUBY_YJIT_ENABLE: 1
    steps:
      - name: Check out repo
        uses: actions/checkout@v4.1.2
        with:
          fetch-depth: 0

      - name: Setup Ruby
        # yamllint disable-line rule:line-length
        uses: ruby/setup-ruby@d4526a55538b775af234ba4af27118ed6f8f6677  # v1.172.0
        with:
          rubygems: 3.5.6
          bundler-cache: true

      - name: Build with Jekyll
        env:
          JEKYLL_ENV: production
        run: bundle exec jekyll build --verbose --baseurl ''

      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3.0.1

ldemailly added a commit to ldemailly/laurentsv that referenced this issue Jun 26, 2024
@ldemailly
Copy link

if anyone is interested, this made it finally work:
https://github.com/ldemailly/laurentsv/blob/master/.github/workflows/jekyll-gh-pages.yml

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests