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 +5 -16
2 changed files with 5 additions and 16 deletions
Download patch file Download diff file Expand all files Collapse all files
Showing only changes of commit 4bb0b05635 - Show all commits

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

@ -10,13 +10,8 @@ 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
# Forgejo Runner seems to modify the HOME variable when it's running a job
# in a Docker container, so we have to find the home directory another way,
# inspired by this StackOverflow answer:
#
# https://unix.stackexchange.com/a/247582
#
- id: find-home
run: eval echo "home=~$(whoami)" >> $GITHUB_OUTPUT
# Assume we remain in the top-level directory of the checkout:
- 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: ${{ steps.find-home.outputs.home }}/.cargo/bin
working-directory: ci-bin
- run: export PATH="$(pwd)/ci-bin:$PATH"

8
.gitignore vendored
View file

@ -1,8 +1,2 @@
node_modules
site
docbuild
__tests__
coverage
dyna3.zip
tmpproj
ci-bin
*~