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

RFE: Fail if listener hasn't started because of github action type. #265

Open
rafaeldtinoco opened this issue Jul 25, 2024 · 4 comments
Open
Assignees
Labels
bug Something isn't working enhancement New feature or request

Comments

@rafaeldtinoco
Copy link

Describe the feature or problem you’d like to solve

When running listen.dev action in any workflow, if the method isn't supported (like a manual trigger, for example), it should fail the run so the user knows it is not working (instead of failing silently and not showing anything in the dashboard).

image

Proposed solution

I spent sometime trying to figure out why the detections were not happening in the manual triggering. Then I opened the listen steps and saw that message. I didn't think there was a problem as there wasn't a failure.

Additional context

N/A.

@rafaeldtinoco rafaeldtinoco added enhancement New feature or request bug Something isn't working labels Jul 25, 2024
@leodido
Copy link
Member

leodido commented Jul 26, 2024

This is because the initial reporter (the comment one) could only work on pull requests:

if !env.IsGitHubPullRequest() {

Since the pro reporter (the one that writes to https://dashboard.listen.dev) can also work on other events (for example on push GitHub events) we could think of removing this check here (1)

if info.IsGitHubPullRequest() {

Of course, by doing so, we accept that this will work only when the https://github.com/listendev/action gets ci: only input.

In fact, with ci: true both reporters run (the gh-pull-comment AND the pro). In this case, the gh-pull-comment will error, causing the action to error.

A possible solution (2), in this last case, could be to detect that the gh-pull-comment is running together with the pro reporter and in this case, force the CLI to not fail/error.

Anyways, I would start implementing (1) for now.

WDYT

@leodido
Copy link
Member

leodido commented Jul 26, 2024

A (3) third solution, would be like you propose.

If the action cannot run on the current GitHub event, let it fail blocking the CI workflow of the user/customer.

But this was something that - in the past - I was explicitly asked not to let happen because it was causing friction to users/customers.

@leodido leodido self-assigned this Jul 26, 2024
@rafaeldtinoco
Copy link
Author

I like making it work in all cases because then testing Argus will be super easy, its just a click in a well known and existing workflow within the repo. So, I'm +1 for that IF possible/feasible.

THanks a lot for all the feedback.

@leodido
Copy link
Member

leodido commented Jul 30, 2024

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

No branches or pull requests

2 participants