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

Job UI #4

Open
alachaum opened this issue Feb 11, 2020 · 2 comments
Open

Job UI #4

alachaum opened this issue Feb 11, 2020 · 2 comments
Labels
enhancement New feature or request

Comments

@alachaum
Copy link
Member

It would be useful to provide an optional UI - at least in development mode - showing the list of jobs pending, running, which ones have failed and the failure reason.

@alachaum alachaum added the enhancement New feature or request label Feb 11, 2020
@lovitt
Copy link

lovitt commented Sep 22, 2024

@alachaum Curious what your current thinking is on a potential Cloudtasker UI?

The Google Tasks UI works OK for basic functions (monitoring, retrying, canceling) in production. But the base64-encoding of job names and arguments makes it hard to see what is going on. And of course there is no visibility into batch jobs.

I was wondering if a Mission Control adapter for Cloudtasker would be feasible. Non-ActiveJob functionality (batches, unique jobs, cron) would not be supported. But Mission Control already supports the notion of adapter-specific features, so perhaps this could be overcome.

Otherwise a purpose-built Cloudtasker UI would be welcome.

We are invested in Cloudtasker and Cloud Tasks for running background jobs. The lack of a good production dashboard UI is our only major pain point at the moment. I'd be more than happy to contribute to developing a solution.

@alachaum
Copy link
Member Author

Hey @lovitt , my initial thinking was to deliver this UI only for development purposes, to give more visibility into failed jobs. As such, I was tempted to simply reuse and adapt the Sidekiq UI since it is completely self-contained.

Having said that, I'm pretty open to solutions. In any case, I think it is preferable to encapsulate this UI in a separate gem. This would give people control over whether or not they want to include this UI (and any gem it would depend on) in their production build.

The bulk of the UI should be a separate gem but we can always extend the core Cloudtasker adapter interfaces and add methods to easily list jobs (with pagination), cancel jobs, etc.

Providing the programmatic API above is probably the first logical step on core Cloudtasker. Once this is in place, the rest is more or less adaptation + cosmetic.

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

No branches or pull requests

2 participants