summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authoriximeow <me@iximeow.net>2023-06-25 04:43:56 -0700
committeriximeow <me@iximeow.net>2023-06-25 04:43:56 -0700
commitc554544ea2455e8a414d3d75a9607ca1fa258e6a (patch)
treea660aae8f71808d63df84379e0681fa85f2ebf66
parenta10f2fdf88a1f3f3ea56901d5dc31a3a2e5a38ff (diff)
formatting in readme
-rw-r--r--README.md12
1 files changed, 6 insertions, 6 deletions
diff --git a/README.md b/README.md
index af1e3cb..91994c6 100644
--- a/README.md
+++ b/README.md
@@ -9,14 +9,14 @@ notably:
* anyone can run CI jobs (if the server is willing to talk to you)
* (soon) the CI runner should be able to run locally in a `watch` manner - CI builds should be testable before reaching CI
* i explicitly intend this system to support non-github triggers
- [ ] say, post-recv hooks in other git repos
- [ ] or a patched cgit to show build statuses
- [ ] or a cron job for non-build-oriented work that should none the less be repeatable
+ [ ] say, post-recv hooks in other git repos
+ [ ] or a patched cgit to show build statuses
+ [ ] or a cron job for non-build-oriented work that should none the less be repeatable
* i expect this system to have first-class support for capturing metrics from builds and reporting on changes
- [ ] and yes, i expect build-o-tron to double as a performance testing environment
- [ ] including replaying a history of build jobs on a new runner to establish performance baselines and differences
+ [ ] and yes, i expect build-o-tron to double as a performance testing environment
+ [ ] including replaying a history of build jobs on a new runner to establish performance baselines and differences
* it knows how to send emails nagging me about builds and their outcomes. other tools can do this too i'm sure, but i can make these useful.
-[ ] in the future, figure out how to do certain kinds of limited deployments after successful goodfile executions. probably goodfile extensions to do those deployments, so success implies successful deployments.
+[ ] in the future, figure out how to do certain kinds of limited deployments after successful goodfile executions. probably goodfile extensions to do those deployments, so success implies successful deployments.
this will probably grow into a general task scheduler, if my interest stays here. i've built at least one of those before.