Discussion

[gillchristian]

Webhook should resolve the request instantly and then run the job (eg. what if one of the commands is sleep 60). We should probably have some sort of queue that process one job (per project?) at a time. Queue should also drop all the other jobs from the same project and just run the last one.

About the logs and history of jobs. I guess we should write the logs to some specific file, maybe create a file per job (eg. give the jobs some id).

But then, what if we keep track of (say the last 5?) jobs and allow to view them in a UI? For the first iteration we don't need an actual UI, could be just JSON. There we could see all the jobs: status, logs, some metadata as well. Eventually (v10 or something) we could even stream the logs to see the job running live 😏

About the environment. I'm thinking we should clear the env vars (Command::new("ls").env_clear()) so the job runs on a clear state. Thresh could also set some env vars (eg. what job is being run, etc). And we could allow loading an .env file and also listing some env vars (in the config file) that should not be cleared.

[ndelvalle]

Webhook should resolve the request instantly and then run the job (eg. what if one of the commands is sleep 60). We should probably have some sort of queue that process one job (per project?) at a time. Queue should also drop all the other jobs from the same project and just run the last one.

Yep, let's just return a successful status code after each webhook and then process the jobs.
I agree, but I think the first iteration should just process all webhooks and not drop similar webhooks.

About the logs and history of jobs. I guess we should write the logs to some specific file, maybe create a file per job (eg. give the jobs some id).

I like the idea of keeping logs on different files so it is easier to look for job history. What I do not like is having to tail n amount of files to check live logs.

But then, what if we keep track of (say the last 5?) jobs and allow to view them in a UI? For the first iteration we don't need an actual UI, could be just JSON. There we could see all the jobs: status, logs, some metadata as well. Eventually (v10 or something) we could even stream the logs to see the job running live 😏

😏 it would be awesome! But yeah I agree, v10.

About the environment. I'm thinking we should clear the env vars (Command::new("ls").env_clear()) so the job runs on a clear state. Thresh could also set some env vars (eg. what job is being run, etc). And we could allow loading an .env file and also listing some env vars (in the config file) that should not be cleared.

Agree, I think we can provide some default env vars and allow the user to set new ones, but IMO we do not want to inherit env vars from the process we are running.