From 435416d05e5d76ac7d3b56c42fc3e7e85745d303 Mon Sep 17 00:00:00 2001 From: jon-lee Date: Wed, 11 Jun 2025 23:10:16 +0800 Subject: [PATCH] docs: adding some details --- JOJ3-Forge-configuration-documentation-for-TAs.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/JOJ3-Forge-configuration-documentation-for-TAs.md b/JOJ3-Forge-configuration-documentation-for-TAs.md index 2c14694..0f72582 100644 --- a/JOJ3-Forge-configuration-documentation-for-TAs.md +++ b/JOJ3-Forge-configuration-documentation-for-TAs.md @@ -41,12 +41,18 @@ The conventional type should be: - **revert**: revert the commits pushed before Basic rules: -- health check is **always** run first + +- health check should **always** run first - all non JOJ stages are run on each push - JOJ is only triggered if `joj` appears in `message` +- `build` should be included in the commit message if you want to compile the program +- a proper formatted case can be `type(scope): message [build joj]` Scope usage: -- `scope` must match JOJ configuration tree (`home/tt/.config/joj` subtree in `course-joj` repo), eg. if tree is `h1/ex2` the `scope` must be `h1/ex2`, if tree is `hw4/1` then scope is also `hw4/1`. + +- `scope` must match JOJ configuration tree (e.g. `/home/tt/.config/joj` subtree in `course-joj` repo), eg. if tree is `h1/ex2` the `scope` must be `h1/ex2`, if tree is `hw4/1` then scope is also `hw4/1`. + - the configuration tree is defined in `push.yaml` and `release.yaml`, for example it can be `/home/tt/.config/joj/hidden` or `/home/tt/.config/joj/students`. + - a sample commit message can be `feat(h2/ex2): h2/ex2 submission [build joj]` - if a scope is invalid then return a warning containing the list of valid scopes and exit nicely (either this is a typo, or this an exercise that do not require coding) - as health check must always be run, `scope` should be checked after it @@ -54,8 +60,7 @@ Refer to [Introduction to JOJ3](/Introduction-to-JOJ3.md) for more details on JO ### TOML configuration format -All configurations files at human level must be written in TOML format. They will then be parsed to generate long and complete `.json` files that can be understantood by JOJ3. -Refer to [TOML reference guide](https://toml.io/en/v1.0.0). After writing a configuration file it is recommended to check its validity, eg. [TOML Lint](https://www.toml-lint.com/). +All configurations files at human level must be written in TOML format. They will then be parsed to generate long and complete `.json` files that can be understantood by JOJ3. Refer to [TOML reference guide](https://toml.io/en/v1.0.0). After writing a configuration file it is recommended to check its validity, eg. [TOML Lint](https://www.toml-lint.com/). Converting the file into JSON format can help better visualize the structure which can be especially helpful when working with arrays of tables.