aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/src/CMakeLists.txt (follow)
Commit message (Collapse)AuthorAge
* test: add test for segfaulting CI scriptEgor Tensin2023-07-11
| | | | | | | | The C code leaked out of src/, so I moved .clang-format and some compile options to the root directory. Also, I'm starting to hit test execution limits; I'm going to limit the repositories used for stress testing.
* store process output in SQLiteEgor Tensin2023-07-09
|
* support code coverage report generationEgor Tensin2023-07-07
|
* cmake: fix Valgrind runs with Clang buildsEgor Tensin2023-07-06
|
* move custom message parsing to a separate moduleEgor Tensin2023-07-04
|
* show git hash with --versionEgor Tensin2023-06-30
| | | | Also, use cmake's configure_file to build string constants in.
* log: support logging levelsEgor Tensin2023-06-28
|
* cmake: fix grammar in option descriptionEgor Tensin2023-06-13
|
* cmake: why the hell would I need MSVC optionsEgor Tensin2023-06-13
|
* use signalfd to stop on SIGTERMEgor Tensin2023-06-13
| | | | | | | | | | | | | | | | | | Is this an overkill? I don't know. The thing is, correctly intercepting SIGTERM (also SIGINT, etc.) is incredibly tricky. For example, before this commit, my I/O loops in server.c and worker.c were inherently racy. This was immediately obvious if you tried to run the tests. The tests (especially the Valgrind flavour) would run a worker, wait until it prints a "Waiting for a new command" line, and try to kill it using SIGTERM. The problem is, the global_stop_flag check could have already been executed by the worker, and it would hang forever in recv(). The solution seems to be to use signalfd and select()/poll(). I've never used either before, but it seems to work well enough - at least the very same tests pass and don't hang now.
* cmake: disable -Werror for debug buildsEgor Tensin2023-05-15
|
* rework server-worker communicationEgor Tensin2023-05-15
| | | | | | | | | | | | | | | | | | OK, this is a major rework. * tcp_server: connection threads are not detached anymore, the caller has to clean them up. This was done so that the server can clean up the threads cleanly. * run_queue: simple refactoring, run_queue_entry is called just run now. * server: worker threads are now killed when a run is assigned to a worker. * worker: the connection to server is no longer persistent. A worker sends "new-worker", waits for a task, closes the connection, and when it's done, sends the "complete" message and waits for a new task. This is supposed to improve resilience, since the worker-server connections don't have to be maintained while the worker is doing a CI run.
* ci_queue -> run_queueEgor Tensin2023-05-13
| | | | Also, some minor refactoring.
* cmake: document _GNU_SOURCE usageEgor Tensin2023-05-13
|
* use -std=c17 -WpedanticEgor Tensin2023-05-13
|
* add command module to handle request-response communicationsEgor Tensin2023-05-13
|
* cmake: don't install() valgrind.shEgor Tensin2023-05-07
| | | | Turns out, I don't really need to install it for the tests.
* add a cimple-valgrind executableEgor Tensin2023-05-06
|
* cmd_line: read executable name from /proc/self/exeEgor Tensin2023-04-29
|
* dedupe command line routinesEgor Tensin2023-04-29
|
* put SQL headers to a separate directoryEgor Tensin2023-04-11
|
* actually create some tables in SQLite databaseEgor Tensin2023-04-11
|
* create SQLite database on startupEgor Tensin2022-09-11
|
* docker: shorten command valuesEgor Tensin2022-08-28
|
* cmake: add install() rulesEgor Tensin2022-08-28
|
* make compilers happierEgor Tensin2022-08-28
|
* holy crap, it actually kinda works nowEgor Tensin2022-08-28
| | | | | | | | | | | | | | | | | | | | | | | Previously, I had a stupid system where I would create a thread after every accept(), and put worker descriptors in a queue. A special "scheduler" thread would then pick them out, and give out jobs to complete. The problem was, of course, I couldn't conveniently poll job status from workers. I thought about using poll(), but that turned out to be a horribly complicated API. How do I deal with partial reads, for example? I don't honestly know. Then it hit me that I could just use the threads that handle accept()ed connections as "worker threads", which would synchronously schedule jobs and wait for them to complete. This solves every problem and removes the need for a lot of inter-thread synchronization magic. It even works now, holy crap! You can launch and terminate workers at will, and they will pick up new jobs automatically. As a side not, msg_recv_and_handle turned out to be too limiting and complicated for me, so I got rid of that, and do normal msg_recv/msg_send calls.
* server: shutting down more gracefullyEgor Tensin2022-08-28
|
* came up with a new name: cimpleEgor Tensin2022-08-26
|
* worker: allow graceful shutdownsEgor Tensin2022-08-26
| | | | | | | | | | Well, maybe "graceful" is a strong word, but now you _can_ do ./server & ./worker & ./client ci_run URL REV && kill "$( pidof worker )" and the worker will wait for the CI run to complete.
* add some more codeEgor Tensin2022-08-26
| | | | | | | | | | | | | | | | This adds a basic "worker" program. You can now do something like ./server & ./worker & ./client ci_run URL REV and the server should pass a message to worker, after which it should clone the repository at URL, checkout REV, and try to run the CI script. It's extremely unfinished: I need to sort out the graceful shutdown, how the server manages workers, etc.
* cmake: ignore unused parameters for nowEgor Tensin2022-08-25
| | | | This is a dumb warning.
* net: rework APIEgor Tensin2022-08-25
| | | | | | | | | | First, rename all API functions so that they start with net_. Second, abstract the basic TCP server functionality into tcp_server.c. This includes reworking net_accept so that it's a simple blocking operation, and putting the callback stuff to tcp_server.c. Also, the server now uses detached threads instead of fork(), since I want connection handlers to share memory.
* cmd -> msgEgor Tensin2022-08-23
| | | | This I feel better conveys the meaning.
* add some codeEgor Tensin2022-08-23
A basic client-server app, the client sends commands as an array of strings. Hopefully I didn't mess up, and hopefully it'll be useful.