Set up continuous integration in Forgejo #75
3 changed files with 21 additions and 14 deletions
|
|
@ -3,22 +3,11 @@ on:
|
|||
push:
|
||||
branches: [main]
|
||||
jobs:
|
||||
# build the application, reporting success if there are no errors or warnings
|
||||
build:
|
||||
runs-on: docker
|
||||
container:
|
||||
image: cimg/rust:1.85-node
|
||||
defaults:
|
||||
run:
|
||||
working-directory: app-proto
|
||||
steps:
|
||||
- uses: https://code.forgejo.org/actions/checkout@v4
|
||||
- uses: ./.forgejo/setup-trunk
|
||||
- run: RUSTFLAGS='-D warnings' trunk build
|
||||
|
||||
# run the automated tests, reporting success if the tests pass and were built
|
||||
# without warnings. the examples are run as tests, because we've configured
|
||||
# each example target with `test = true` and `harness = false` in Cargo.toml
|
||||
# each example target with `test = true` and `harness = false` in Cargo.toml.
|
||||
# Trunk build failures caused by problems outside the Rust source code, like
|
||||
# missing assets, should be caught by `trunk_build_test`
|
||||
test:
|
||||
runs-on: docker
|
||||
container:
|
||||
|
|
@ -28,4 +17,5 @@ jobs:
|
|||
working-directory: app-proto
|
||||
steps:
|
||||
- uses: https://code.forgejo.org/actions/checkout@v4
|
||||
- uses: ./.forgejo/setup-trunk
|
||||
- run: RUSTFLAGS='-D warnings' cargo test
|
||||
|
glen marked this conversation as resolved
Outdated
|
||||
|
|
@ -5,6 +5,9 @@ mod engine;
|
|||
mod outline;
|
||||
mod specified;
|
||||
|
||||
#[cfg(test)]
|
||||
mod tests;
|
||||
|
||||
use rustc_hash::FxHashSet;
|
||||
use sycamore::prelude::*;
|
||||
|
||||
|
|
|
|||
14
app-proto/src/tests.rs
Normal file
14
app-proto/src/tests.rs
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
use std::process::Command;
|
||||
|
||||
// build and bundle the application, reporting success if there are no errors or
|
||||
// warnings. to see this test fail while others succeed, try moving `index.html`
|
||||
// or one of the assets that it links to
|
||||
#[test]
|
||||
fn trunk_build_test() {
|
||||
let build_status = Command::new("trunk")
|
||||
.arg("build")
|
||||
.env("RUSTFLAGS", "-D warnings")
|
||||
.status()
|
||||
.expect("Call to Trunk failed");
|
||||
assert!(build_status.success());
|
||||
}
|
||||
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!