StudioInfinity/dyna3
2
0
Fork 1
Code Issues 56 Pull requests 1 Projects 3 Releases 4 Wiki Activity Actions

Set up continuous integration in Forgejo #75

Merged
glen merged 23 commits from Vectornaut/dyna3:forgejo-ci into main 2025-04-02 20:31:42 +00:00
Conversation 66 Commits 23 Files changed 7 +7 -2
1 changed files with 7 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files
Showing only changes of commit 440b1dfb3d - Show all commits

9
.forgejo/setup-trunk/action.yaml
View file

@ -10,8 +10,13 @@ runs:
using: "composite"
steps:
glen marked this conversation as resolved
glen commented 2025-03-29 00:09:27 +00:00
Copy link

Reviewing this is hampered because I have no idea what using: "composite" means, and https://forgejo.org/docs/next/user/actions/ sheds no light on this. Can you either explain or point to somewhere that has the information?

Reviewing this is hampered because I have no idea what `using: "composite"` means, and https://forgejo.org/docs/next/user/actions/ sheds no light on this. Can you either explain or point to somewhere that has the information?
Vectornaut commented 2025-03-29 05:57:05 +00:00
Copy link

The documentation of Gitea Actions and Forgejo Actions seems to rely a lot on the principle that these are "similar and mostly compatible to GitHub Actions," despite Forgejo's insistence that "they are not and will never be identical." GitHub's description of composite actions is pretty much what I'd guess from the usage here:

A composite action allows you to combine multiple workflow steps within one action. For example, you can use this feature to bundle together multiple run commands into an action, and then have a workflow that executes the bundled commands as a single step using that action. To see an example, check out Creating a composite action.

The documentation of Gitea Actions and Forgejo Actions seems to rely a lot on the [principle](https://docs.gitea.com/next/usage/actions/overview#name) that these are "similar and mostly compatible to GitHub Actions," despite Forgejo's insistence that "they are not and will never be identical." GitHub's [description](https://docs.github.com/en/actions/sharing-automations/creating-actions/about-custom-actions#composite-actions) of composite actions is pretty much what I'd guess from the usage [here](https://forgejo.org/docs/next/user/actions/#inputs): > A composite action allows you to combine multiple workflow steps within one action. For example, you can use this feature to bundle together multiple run commands into an action, and then have a workflow that executes the bundled commands as a single step using that action. To see an example, check out [Creating a composite action](https://docs.github.com/en/actions/creating-actions/creating-a-composite-action).
- run: rustup target add wasm32-unknown-unknown
# Assume we remain in the top-level directory of the checkout:
# install the Trunk binary to `ci-bin` within the workspace directory, which
# is determined by the `github.workspace` label and reflected in the
# `GITHUB_WORKSPACE` environment variable. then, make the `trunk` command
# available by placing the fully qualified path to `ci-bin` on the
# workflow's search path
- run: mkdir -p ci-bin
- run: curl --output - --proto '=https' --tlsv1.2 --retry 10 --retry-connrefused --location --silent --show-error --fail 'https://github.com/trunk-rs/trunk/releases/download/v0.21.12/trunk-x86_64-unknown-linux-gnu.tar.gz' | tar --gunzip --extract --file -
working-directory: ci-bin
- run: echo "$(pwd)/ci-bin" >> $GITHUB_PATH
- run: echo "${{ github.workspace }}/ci-bin" >> $GITHUB_PATH