TODO:
- [x] comment out the `git push` once the website has submodules merged in
Fixes: https://codeberg.org/forgejo/docs/issues/8
Additionally
* Upgrade to node:20
* Exclude the README.md when copying to the preview
* Allow forgejo-website to push to main on website
Preview: https://forgejo.codeberg.page/@docs_pull_9/
Reviewed-on: https://codeberg.org/forgejo/docs/pulls/9
Reviewed-by: Loïc Dachary <dachary@noreply.codeberg.org>
Co-authored-by: Earl Warren <contact@earl-warren.org>
Co-committed-by: Earl Warren <contact@earl-warren.org>
TODO:
- [x] clone from website instead of caesar
- [x] skip the proof of change commit
Preview: https://forgejo.codeberg.page/@docs_pull_5/
This is a simplistic approach to get started with previews. It copies the website, moves the docs under `/forgejo-docs/{{ base branch }}`, create the website and publishes it for preview. No doubt the actual workflow will be different but that needs to be decided.
* Added a WEBSITETOKEN secret created from the forgejo-website user. It is a token with write access to repositories. https://codeberg.org/forgejo/docs/settings/actions/secrets. Contrary to woodpecker it is not in an environment variable but will be replaced when inserting `${{ secrets.WEBSITETOKEN }}` somewhere
* In the environment the variable was replaced CI_COMMIT_PULL_REQUEST → `${{ env.GITHUB_REF_NAME }}`
* The preview is published at https://forgejo.codeberg.page/@docs_pull_N/ instead of https://forgejo.codeberg.page/@pull_N/
* The `$$` were replaced with `$` in the script because Forgejo Actions does not interpret `$` and therefore does not need escaping them to `$$`
Reviewed-on: https://codeberg.org/forgejo/docs/pulls/5
Reviewed-by: Loïc Dachary <dachary@noreply.codeberg.org>
Reviewed-by: Caesar Schinas <caesar@caesarschinas.com>
Co-authored-by: Earl Warren <contact@earl-warren.org>
Co-committed-by: Earl Warren <contact@earl-warren.org>
So it actually is [attachment] or [storage.attachments], one singular
and one plural. One more reason to **not** document [storage.XXXX].
# Conflicts:
# v1.21/admin/config-cheat-sheet.md
# v1.21/admin/storage.md
While feature branches may have different requirements for the Forgejo
tables, they are constrained by the migration logic that requires they
happen in sequence and are listed in the same list. If each feature
branch changes the `forgejo_migrations/migrate.go` file independently,
it is bound to conflict with other feature branches trying to do the
same.
To avoid this situation it is proposed that once a migration
developped and tested in a freature branch is final, it is isolated in
a commit and moved to the `forgejo-development` branch. This can
happen during a rebase or with a pull request.
It is probably better that all migrations are ultimately squashed in a
single commit in the `forgejo-development` branch instead of an ever
growing list of commits. But this is up to the person in charge of the
migrations and since the directory is owned by forgejo, there is no
risk of conflict.
