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

deps: Update .github repo to latest (fix loading PRIVACY_POLICY.md) #267

Merged
merged 1 commit into from
Feb 9, 2024

Conversation

DeeDeeG
Copy link
Member

@DeeDeeG DeeDeeG commented Feb 8, 2024

Ran pnpm up .github with pnpm 7.x latest (pnpm 7.33.6).

Update the commit hash for .github repo in our pnpm-lock.yaml PNPM lockfile, to fetch the latest revision of that repo.

Revision before this PR is too old to include PRIVACY_POLICY.md. This PR's change should pull in the PRIVACY_POLICY.md file, so we can display it on the website.

Fixes #161, probably?


Details:

I believe what Meadow said about it is basically right.

To reiterate and perhaps clarify further:

  • An exact commit SHA of pulsar-edit/.github repo is pinned in the lockfile. This commit is from November 2022.
  • We want a commit SHA of pulsar-edit/.github repo that is at least from December 2022 or newer, when the PRIVACY_POLICY.md was added. See: https://github.com/pulsar-edit/.github/commits/main/PRIVACY_POLICY.md and pulsar-edit/.github@5d2498a.
  • CI is installing with pnpm install --frozen-lockfile (among other CLI arguments), so this dependency will not automatically be updated in CI. But generally I don't expect pnpm install to mess with the lockfile, by default, other than to update to a new lockfile format but retaining the same dependencies/dependency version numbers, just recorded/laid out into the new format.
  • After running pnpm up .github, the issue is fixed for me locally. The @include of PRIVACY_POLICY.md is working.
    • (pnpm up could hang in some cases, maybe just with older pnpm (?), due to some git ls-remote command under the hood hanging and then silently failing??? So, maybe that was giving people trouble at some point? It went away for me after updating to latest pnpm and also deleting my caches, not sure which solved it if either, since I did both at the same time... Also, perhaps it was a network error or me being rate-limited. and it just "went away on its own"/only an intermittent issue in the first place?)
  • I believe it is not working for some people locally perhaps because they left pnpm dev running before updating the dep, relying on the auto-reload feature? But the @includes appear to be processed only once per run of pnpm dev and then retained for the rest of that run... So, one has to quit the dev server and run pnpm dev again to load the new PRIVACY_POLICY.md file into the @include.

@Daeraxa
Copy link
Member

Daeraxa commented Feb 9, 2024

If it works it works, thanks for fixing it. At worst the change shouldn't make any difference to what we currently have. I had it running in dev before but I guess I never realise that the lockfile was pinned to a particular commit like that - I think I had already just had it with various other pnpm related issues at that point.

@DeeDeeG
Copy link
Member Author

DeeDeeG commented Feb 9, 2024

Thank you for the review!

I will watch the CI and make sure this actually deploys with the fix... Will edit this comment to say how it went. (If I forgot to update it, feel free to ping me!)

[EDIT/UPDATE: Yeah, so the setting for this repo "Pages --> Build and deployment --> Source" needs to be set to "Deploy from a branch", the branch should be "gh-pages", and the folder for that branch should be set to "/ (root)".

I had tried setting the "Source" setting to "GitHub Actions (Beta)" the other day (well, I more just wanted to see the setting and its configuration options, but it auto-applies and saves, if you select it!!), and that appears not to have worked, so I am now reverting the setting to what it was before.

(Tangent/context: I suspected this "GitHub Actions" approach was already how our workflow worked under the hood, and that switching it explicitly to this could avoid the need to manually disable some workflows triggered by pushed to the gh-actions branch by our main "build and deploy" workflow. I appear to have been wrong on this count! The action that finalizes the deploy is the one that GitHub runs for you if you've set the aforementioned "Source" setting to "Deploy from a branch"!! So, disabling that meant no deploy when I merged this!)

The fix: 1) I switched the above-mentioned "Pages --> Build and deployment --> Source" setting back to "Deploy from a branch", "gh-actions" branch, "/ (root)" folder. 2) I navigated to the page for the "Deployment Docs - PNPM" (aka "deploy-pnpm.yaml") GitHub Actions workflow for this repo (here: https://github.com/pulsar-edit/pulsar-edit.github.io/actions/workflows/deploy-pnpm.yaml), and triggered the workflow manually (using the default branch, main).

The deploy has now worked, and the site is updated. Hopefully this slight misadventure helps document our processes and requirements for running this repo... A misadventure frequently comes with a lesson learned, hopefully this write-up adequately shares that lesson...

/EDIT/UPDATE.]

Merging now!

@DeeDeeG DeeDeeG merged commit 34d82f2 into main Feb 9, 2024
2 checks passed
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.

Privacy Policy include not working
2 participants