Set up continuous integration in Forgejo #75
3 changed files with 47 additions and 0 deletions
12
.forgejo/run-examples/action.yaml
Normal file
12
.forgejo/run-examples/action.yaml
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
# run all Cargo examples, as described here:
|
||||
#
|
||||
# Karol Kuczmarski. "Add examples to your Rust libraries"
|
||||
# http://xion.io/post/code/rust-examples.html
|
||||
#
|
||||
runs:
|
||||
using: "composite"
|
||||
steps:
|
||||
- run: cd app-proto; cargo run --example irisawa-hexlet
|
||||
- run: cd app-proto; cargo run --example three-spheres
|
||||
- run: cd app-proto; cargo run --example point-on-sphere
|
||||
- run: cd app-proto; cargo run --example kaleidocycle
|
||||
10
.forgejo/setup-rust/action.yaml
Normal file
10
.forgejo/setup-rust/action.yaml
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
# set up the Rust toolchain. based on David Tolnay's more general
|
||||
# `rust-toolchain` action for GitHub
|
||||
#
|
||||
# https://github.com/dtolnay/rust-toolchain
|
||||
#
|
||||
runs:
|
||||
using: "composite"
|
||||
steps:
|
||||
- run: curl --proto '=https' --tlsv1.2 --retry 10 --retry-connrefused --location --silent --show-error --fail 'https://sh.rustup.rs' | sh -s -- -y --profile minimal
|
||||
- run: echo $HOME/.cargo/bin >> $GITHUB_PATH
|
||||
25
.forgejo/workflows/continuous-integration.yaml
Normal file
25
.forgejo/workflows/continuous-integration.yaml
Normal file
|
|
@ -0,0 +1,25 @@
|
|||
on:
|
||||
pull_request:
|
||||
push:
|
||||
branches: [main]
|
||||
jobs:
|
||||
build:
|
||||
runs-on: docker
|
||||
steps:
|
||||
- uses: https://code.forgejo.org/actions/checkout@v4
|
||||
- uses: ./.forgejo/setup-rust
|
||||
- run: rustup target add wasm32-unknown-unknown
|
||||
- run: cargo install trunk
|
||||
- run: cd app-proto; trunk build
|
||||
test:
|
||||
runs-on: docker
|
||||
steps:
|
||||
- uses: https://code.forgejo.org/actions/checkout@v4
|
||||
- uses: ./.forgejo/setup-rust
|
||||
- run: cd app-proto; cargo test
|
||||
run-examples:
|
||||
runs-on: docker
|
||||
|
glen marked this conversation as resolved
Outdated
|
||||
steps:
|
||||
- uses: https://code.forgejo.org/actions/checkout@v4
|
||||
- uses: ./.forgejo/setup-rust
|
||||
- uses: ./.forgejo/run-examples
|
||||
Loading…
Add table
Reference in a new issue
Why isn't this path
../.forgejo/setup-trunk? That would seem to be the relative path from the working-directory to the action. I mean, I am not suggesting the file is incorrect; I am just saying the notation is unclear, and my particular concern is that when we (presumably sometime soon) remove the app-proto layer of the hierarchy, that this workflow file be reasonably resilient to that.I think the label
defaults.run.working-directorysets the default only forrunsteps, like in GitHub Actions.How is the working directory for a uses step determined then? Should that be made explicit in this file somehow?
In meeting, we concluded that Aaron will push a commit that adds some mild commentary he is comfortable with elucidating how the current directory state is evolving during this workflow.
In the
setup-trunkaction, you added the comment: "Assume we remain in the top-level directory of the checkout." It seems to me, though, that it doesn't really matter wheresetup-trunkruns: Trunk will be added to the path regardless. What were you thinking might go wrong ifsetup-trunkran somewhere else? Or was this comment just meant to indicate that, for the sake of organization,setup-trunkshould be run from the top-level directory of the checkout?The GitHub Actions documentation is clearer about how the path to a local action is specified. This is consistent with the behavior I've seen in Forgejo Actions.
What I meant was: it was our intention that trunk be installed in a directory ci-bin created at the top level of the project hierarchy. The script as written only accomplishes that intention if it in fact is the case that post the
run: rustup...action it remains that case that the current directory is the top-level directory. [Sorry about the delay in posting this, apparently I forgot to hit the Reply button last night when I wrote it, and only discovered that omission today when I started closing all of my numerous open browser windows.]Ah, and now we have crossed to some extent. When you push clarifying comments as you see fit for the location of the uses action and/or what the checkout does to the current directory (I think those are the points we discussed, feel free to adjust the comment I put in to the setup-trunk action so that my intended meaning is clearer. Thanks!
Got it! It turns out that the
setup-trunkaction doesn't actually do that, because I was wrong during the meeting about how location control works in actions. The workflow comes with a workspace directory, which is the default place to run commands and place files that are shared between steps. This is mentioned in the Forgejo Actions glossary:As of commit
efb2d39, thesetup-trunkaction createsci-binwithin the workspace directory, even if we tell thecheckoutaction to check the repository out to somewhere else.I've made a second commit (
440b1df) that adjusts your comment and makes the location used insetup-trunkmore explicit. Feel free to revert or modify it if you'd like.@Vectornaut wrote in #75 (comment):
Agreed, but because it installs ci-bin as as a subdirectory of the workspace, and it checks out the repository so that its top-level directory is exactly the workspace, the ci-bin directory does end up at the top level of the checkout (as verified by an explicit
lsstep I temporarily put in the workflow). As a consequence, I clarified the comments on checkout to note exactly where the top-level directory of the repo ends up, and I leftci-binin.gitignorebecause in CI, that's where it ends up, so if somehow ever (A) the CI steps ran directly in the host [hard to imagine] or (B) we had a CI action that created a commit [slightly more plausible, even if unlikely], the ci-bin directory would be ignored. With those changes, I am resolving this conversation, and merging the PR. Thanks for all of your efforts on this!