mirror of
https://codeberg.org/Codeberg/Documentation.git
synced 2026-08-15 14:53:29 -07:00
33094726bb
This should reduce support load for first-deployment TLS issues. Reviewed-on: https://codeberg.org/Codeberg/Documentation/pulls/825 Reviewed-by: Bastian Greshake Tzovaras <gedankenstuecke@noreply.codeberg.org>
53 lines
2.6 KiB
Markdown
53 lines
2.6 KiB
Markdown
---
|
||
eleventyNavigation:
|
||
key: Deploying directly from Forgejo Actions
|
||
title: Deploying directly from Forgejo Actions
|
||
parent: CodebergPages
|
||
order: 100
|
||
---
|
||
|
||
Git-pages has an [associated Forgejo Action](https://codeberg.org/git-pages/action) that can be used to automatically deploy your website from a static site generation tool.
|
||
You can use any such tool you like: git-pages does not privilege any particular publishing system over others.
|
||
|
||
If you already use a static site generator and/or already use Forgejo Actions, using the pre-made Forgejo Action is by far the simplest and most efficient way to publish your site to Codeberg Pages.
|
||
|
||
To use it, simply add it as a final step to your workflow:
|
||
|
||
{% raw %}
|
||
|
||
```yaml
|
||
- uses: https://codeberg.org/git-pages/action@v2
|
||
with:
|
||
site: 'https://${{ forge.repository_owner }}.codeberg.page/repository-name/'
|
||
server: codeberg.page
|
||
token: ${{ forge.token }}
|
||
source: _site/
|
||
```
|
||
|
||
{% endraw %}
|
||
|
||
Replace `repository-name` in the `site` parameter with the name of your repository.
|
||
If your repository is also called `pages`, you can also omit the repository name and deploy directly to the site `https://username.codeberg.page/`.
|
||
|
||
The `source` parameter should point to the directory (relative to the root, after all previous steps in your workflow) where your site generator has put the generated version of your site.
|
||
This directory can also contain the `404.html` and `_redirects` files to customize your site’s behavior, as described in the [advanced documentation](/codeberg-pages/advanced-usage/).
|
||
|
||
The `token` will automatically be filled by Forgejo Actions with a secret token, which in turn will automatically be recognized by git-pages as authorizing this workflow to publish to this site.
|
||
|
||
{% admonition "Warning" %}
|
||
|
||
If you use branches to test out new features, write draft blog posts, etc., you should either limit the whole workflow, or this step only, to pushes to a default branch (usually `main` or `master`) to ensure that only finalized content is published to your site.
|
||
|
||
To do this, either add a [`on.push.branches` list](https://forgejo.org/docs/latest/user/actions/reference/#onpush) to the whole workflow, or add [an `if` condition to the step](https://forgejo.org/docs/latest/user/actions/reference/#jobsjob_idstepsif-1) (or [to the whole job](https://forgejo.org/docs/latest/user/actions/reference/#jobsjob_idif)) like this:
|
||
|
||
{% raw %}
|
||
|
||
```yaml
|
||
if: ${{ forge.ref == 'refs/heads/main'}}
|
||
```
|
||
|
||
{% endraw %}
|
||
|
||
This will limit deploys so they only happen when CI is triggered by a push to the `main` branch.
|
||
|
||
{% endadmonition %}
|