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.
For each page of the documentation that has some content originating from Gitea, incorporate the updates.
git diff 62ac3251fa545d32bdfc9ff824106b97ec63edbb..faa28b5a44912f1c63afddab9396bae9e6fe061c -- $(find . -type f -name 'en-us')
Where faa28b5a44912f1c63afddab9396bae9e6fe061c is Gitea main as of today.
It is supposed to reflect the help of `forgejo --help`. However, since
it is manually maintained there are differences that may be confusing.
It could be generated with `forgejo docs` but the format is not good
enough as it is.
# Conflicts:
# admin/command-line.md
