Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make incoming test reports trigger backend processing jobs #5

Closed
preaction opened this issue May 5, 2017 · 2 comments
Closed

Make incoming test reports trigger backend processing jobs #5

preaction opened this issue May 5, 2017 · 2 comments

Comments

@preaction
Copy link
Member

Once we have a test reports feed (cpan-testers/cpantesters-api#6) we should listen to the feed to trigger new processing jobs.

The existing processing job (#1) should be modified to use Beam::Minion to queue a job. Each job should process one report.

We will need one daemon to watch the feed and trigger the jobs. This daemon should listen for each feed and then queue a job with the data. This daemon should be monitored by a runit file.

There will need to be an API in Beam::Minion to queue new jobs with arbitrary data (not just the command-line arguments of the current API) (see: preaction/Beam-Minion#1).

@preaction
Copy link
Member Author

This needs to be done as soon as possible: The scanning of the entire database for unprocessed entries takes much too long. There might be a way to fix that problem, but it will simply be easier to make incoming reports trigger individual processing jobs.

@preaction
Copy link
Member Author

This has been completed by cpan-testers/cpantesters-api@2842283 and ecbfbf4 so this can be closed. There's another way to do this which involves message-passing via Mercury (cpan-testers/cpantesters-api#6) and a daemon that knows how to queue up processing jobs based on messages, but that's another ticket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant