TODO:
- comment out the
git pushonce the website has submodules merged in
Fixes: #8
Additionally
-
Upgrade to node:20
-
Exclude the README.md when copying to the preview
-
Allow forgejo-website to push to main on website
pr-push-update-website into next TODO:
git push once the website has submodules merged inFixes: #8
Additionally
Upgrade to node:20
Exclude the README.md when copying to the preview
Allow forgejo-website to push to main on website
da3577d91e
28667d7a68
28667d7a68
d158ab7a75
d158ab7a75
88331cc723
5c8aac2508
55016675a0
55016675a0
61d98d8832
6ef914fd36
a5e234bb87
@ -17,2 +16,2 @@
mkdir -p /tmp/website/forgejo-docs/${{ env.GITHUB_BASE_REF }}
cp -a * /tmp/website/forgejo-docs/${{ env.GITHUB_BASE_REF }}
apt-get update -qq && apt-get install -qq -y rsync
rsync -av --exclude=README.md --delete ./ /tmp/website/forgejo-docs/${{ env.GITHUB_BASE_REF }}/
I don't think there should be any need to exclude README.md. The file layout in forgejo/website#331 was designed such that only the content of the docs and images subfolders will make it to the live website.
I prettyfied the README so it passes CI on the website
@ -0,0 +22,4 @@
git config user.email "ci@forgejo.org" ; git config user.name "forgejo-website"
git add .
git diff-index --quiet HEAD || git commit -m 'publish' -a
git push
For the actual publish we presumably need to push to Uberspace rather than to the Pages repo.
Here the push is to the website repo. Which will, in turn, publish to Uberspace.
It is cascading, the docs repository is not responsible for updating the website.
Oh, sorry, I wasn't paying attention. Need more coffee!
But in that case I'm not sure about this approach – I don't think there's any need to commit to the website repo every time a change is made to the docs, that will just clutter the website history.
Wouldn't it be better to just trigger the website CI, which already pulls in the latest docs every time it's run?
Wouldn't it be better to just trigger the website CI, which already pulls in the latest docs every time it's run?
I'm not sure how to do that.
that will just clutter the website history.
It will update the submodules which ensures consistency. Failing that the https://forgejo.org content will not match what someone gets when looking at git clone --recursive https://codeberg.org/forgejo/website because the submodules may be out of date.
I'm not sure how to do that.
Ah, well if you don't know, I'm sure I don't. I had "assumed" we could trigger that action via a webhook but I've no idea if that's true.
I guess an alternative would be to push straight to Uberspace – since we're building the whole website here for PRs anyway we could just do the same thing?
It will update the submodules which ensures consistency. Failing that the https://forgejo.org content will not match what someone gets when looking at git clone --recursive https://codeberg.org/forgejo/website because the submodules may be out of date.
I guess that's true – it doesn't affect the actual website because the CI pipeline already pulls the latest version, but it will affect local previews.
One workaround would be to just make the pnpm dev and pnpm build commands run git submodule update --remote first.
I still feel it would be much cleaner to avoid a load of commits just updating the submodule commit SHAs, but I can also understand the argument in favour, so in the end I'm happy to go with whatever others think is best here.
One workaround would be to just make the
pnpm devandpnpm buildcommands rungit submodule update --remotefirst.
Actually a cleaner solution would probably be to to it in a post-checkout hook.
This is an interesting idea. Never used those.
@ -0,0 +1,48 @@
name:pr
Is this file supposed to be committed?
Good catch, I'll remove it.
Unable to find current origin/v1.19 revision in submodule path 'forgejo-docs/v1.19'
That's a strange error 🤔
I'm on it.
e5f9be2774
8c4fb67823
8c4fb67823
9453ac7017
README.md fixed, should be good to go now.
I merged in haste because a test run broke the CI of the website.
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?