Improve build awareness #314

New Issue

Jef Roosens · 2022-12-17T11:59:45+01:00

Jef Roosens commented

2022-12-17 11:59:45 +01:00

Currently the build system is completely unaware of what's happening. An agent just receives a build and the server forgets about it. An agent also doesn't track why a build fails, etc. This issue is a tracker issue for listing some improvements.

Builds should report what command caused them to fail.
This could be done by searching through the logs for the last log line that starts with + and matches one of the commands of the build
If the failed command is a makepkg call, a more detailed error report should be shown (e.g. parse the status code & show the correct name as lasted in the man page)
Instead of a logs api, we should switch to a jobs api.
- A scheduled job should receive an id
- When a job is poll'ed, the job's status should be changed to "running" or something like that
- When an agent then sends back the results of the job, the server can know the job finished (either successfully or not)
- The server can add a timeout to jobs, to cover the case where an agent unexpectedly couldn't finish a job
- Agents should also have an option to time out jobs, although this timeout should be shorter than the server one.
- I'd like to look into the job queue, as a way to see what the server is doing etc.
Build containers should exit when a command fails
- This could be done with set -e (although this adds a hard Bash dependency)
Some builds take longer than others, and not all build agents are the same. Therefore, it might be interesting to analyze the build times of packages, and perhaps schedule them differently depending on what agents are available and how powerful they are.

Currently the build system is completely unaware of what's happening. An agent just receives a build and the server forgets about it. An agent also doesn't track why a build fails, etc. This issue is a tracker issue for listing some improvements. * Builds should report what command caused them to fail. This could be done by searching through the logs for the last log line that starts with `+ ` and matches one of the commands of the build * If the failed command is a `makepkg` call, a more detailed error report should be shown (e.g. parse the status code & show the correct name as lasted in the man page) * Instead of a `logs` api, we should switch to a `jobs` api. * A scheduled job should receive an id * When a job is poll'ed, the job's status should be changed to "running" or something like that * When an agent then sends back the results of the job, the server can know the job finished (either successfully or not) * The server can add a timeout to jobs, to cover the case where an agent unexpectedly couldn't finish a job * Agents should also have an option to time out jobs, although this timeout should be shorter than the server one. * I'd like to look into the job queue, as a way to see what the server is doing etc. * Build containers should exit when a command fails * This could be done with `set -e` (although this adds a hard Bash dependency) * Some builds take longer than others, and not all build agents are the same. Therefore, it might be interesting to analyze the build times of packages, and perhaps schedule them differently depending on what agents are available and how powerful they are.

Jef Roosens added the

idea

label 2022-12-17 11:59:45 +01:00

Jef Roosens added this to the 0.6.0 milestone 2022-12-29 10:20:16 +01:00

Jef Roosens modified the milestone from 0.6.0 to 0.7.0

2023-06-04 09:14:24 +02:00

Sign in to join this conversation.