Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add fetch-depth note to git last modified and git created #1656

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

alifeee
Copy link

@alifeee alifeee commented Jan 25, 2024

Add note

  • This needs an entire git history (which is often not the case in CI environments) or it will return the date of checkout. Fetch the entire history in your CI, for example in GitHub by setting fetch-depth: 0 with GitHub's checkout action.

to git Last Modified and git Created on the Content Dates page

Most CIs checkout a shallow copy of the repository, in which case the git Created and git Last Modified dates will be wrong. This reminds people to disable shallow-cloning if using these two date types.

For example, in GitHub actions you must run

      - name: Checkout
        uses: actions/checkout@v4
+       with:
+         fetch-depth: "0"

for git Created and git Last Modified to work with Eleventy on the runners

@Snapstromegon
Copy link
Member

Hi @alifeee thanks for the suggestion.
Do you know if it's possible to detect a shallow clone from within the repo so we could display a warning in those cases when the git dates are used?

I like the first sentence of your note, but I'm a little torn on the second because of the way it's written. I will think about it if I find a better fitting version - otherwise I will merge this this weekend.

@alifeee
Copy link
Author

alifeee commented Jan 25, 2024

it looks like a shallow repository can be detected by (source):

git rev-parse --is-shallow-repository

Would this be better as a warning or an error? If it was a warning then it would not be that visible on a CI system? I'm not the most knowledgeable about what happens to emitted warnings.

Perhaps it would appear under people's workflows?

Anyway if this were the case then we might not need a warning in the docs here. What do you think?

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

Successfully merging this pull request may close these issues.

2 participants