Feat: Skip request

[JorgeTrovisco]

Description

Adds the feature mentioned on #2116. This functionality is important because some endpoints cannot be tested recurrently when we invoke complex APIs. This way we can keep these endpoints in the collection with examples and documentation without running the risk of invoking them in the collection run.

Contribution Checklist:

• The pull request only addresses one issue or adds one feature.
• The pull request does not introduce any breaking changes
• I have added screenshots or gifs to help explain the change if applicable.
• I have read the contribution guidelines.
• Create an issue and link to the pull request.

Screenshots

[martinsefcik]

I would probably omit this Skipped OK blue text in brackets for skipped requests. Normally there is HTTP status and skipped request has no HTTP status. So we are mixing apples and pears in this brackets. Also putting OK there doesn't make sense to me as skipping cannot fail. So every skipped request will be always OK.

[JorgeTrovisco]

[sanjai0py]

Hey @JorgeTrovisco, thanks for creating this PR. I will test it and get back to you soon!

[nikischin]

I just checked out your branch locally and run into this issue if I try to use the new function:

Same thing happens if I remove the if before the skip condition, but doesn't happen if I remove the skip function call. Did I do it wrong? If yes I would recommend to implement some intuitive error handling

[nikischin]

What's the reason item.responseReceived is set here?
Seems like a copy paste mistake but I could be wrong.
I would expect action.payload.responseReceived to be undefined when the request is skipped so item.responseReceived would be as well?

Also why are we using .find() here, whereas all the other types use .findLast()?

[JorgeTrovisco]

Hi,

You're right, responseReceived is no longer necessary.

Regarding the find vs findLast change, it was made after I checked out the branch, so I didn't catch it during the merge.

[nikischin]

Thank you so much for your fast reply! Looks very good (on code level)

So have you been able to reproduce my error or do I need to set up some collection to reproduce the error?

Or did I use the function not as intended?

[JorgeTrovisco]

I just checked out your branch locally and run into this issue if I try to use the new function: Same thing happens if I remove the if before the skip condition, but doesn't happen if I remove the skip function call. Did I do it wrong? If yes I would recommend to implement some intuitive error handling

I can't reproduce the error. Can you share your collection?

bru.skipRequest();

If I use the skipRequest on the current bruno I receive the following

[martinsefcik]

Shouldn't it be also implemented for bruno-cli ?

[nikischin]

So this is the smallest reproducible example I was able to build:

example.bru

meta {
  name: example
  type: http
  seq: 4
}

get {
  url: https://api.restful-api.dev/objects
  body: none
  auth: none
}

script:pre-request {
  if(!bru.getEnvVar("sampleVar")){
    bru.skipRequest();
  }
}

For reproduction it is the easiest to set up a new ENV with the var sampleVar set to some random value. Whenever you have selected this environment, the request will go through without being skipped, and when you select "No Environment" it will fail with the error provided.

[JorgeTrovisco]

The skip request is just for collection running, so when you execute the request manually it should still be executed.

It works without the creation of the environment variables? Is the error related with trying to get a unavailable variable?

[nikischin]

The skip request is just for collection running, so when you execute the request manually it should still be executed.

It works without the creation of the environment variables? Is the error related with trying to get a unavailable variable?

It seems not to be related to getting an undefined environment variable.

In the published version of bruno (without the skip function implemented) it just executes the request and does get the response as usual (so does nothing regarding skipping obviously).

(As you can see I don't have any environment selected so the variable cannot be defined).

Also being able to use the skip function only for the runner in my opinion is not intuitive. This is definitely subject to discussion but I would expect it to also skip on standalone run. As you can see there might be many reasonable examples why you might want to skip a run and in my opinion it doesn't make a difference if it's from within the runner or standalone.

I personally would even implement a condition to skip any call (pre request script on collection level) whenever some auth token is not set or something, as it is not beneficial to even run requests I know for sure that would not run or would not be beneficial to test or might even cause other problems.

[JorgeTrovisco]

Still no luck at reproduce the error, however I found a bug that exists on main

The first element of the list does not have the OK after 200. Should I open an issue to fix this error?

[JorgeTrovisco]

Also being able to use the skip function only for the runner in my opinion is not intuitive. This is definitely subject to discussion but I would expect it to also skip on standalone run. As you can see there might be many reasonable examples why you might want to skip a run and in my opinion it doesn't make a difference if it's from within the runner or standalone.

• Using that approach, I'd have to remove the skip request each time I want to test the endpoint, then add it back when I run the collection.
• If I don't want to run a standalone request, I simply won't press the "send" button.

[nikischin]

Still no luck at reproduce the error, however I found a bug that exists on main

The first element of the list does not have the OK after 200. Should I open an issue to fix this error?

Have you tried executing the single request I provided in my example (not from within the runner) by just using the arrow button on the top right?

Regarding your finding, feel free to open a bug with a reproducible example. I was able to reproduce it with one of my collections but not in another. So this seems to happen only for some cases.

[JorgeTrovisco]

I still haven't had any luck reproducing that behavior.

I used your .bru file and set up the environment variables. It worked successfully both with and without the environment, and I was able to skip the request during the collection run based on the environment variable.

[nikischin]

Also being able to use the skip function only for the runner in my opinion is not intuitive. This is definitely subject to discussion but I would expect it to also skip on standalone run. As you can see there might be many reasonable examples why you might want to skip a run and in my opinion it doesn't make a difference if it's from within the runner or standalone.

• Using that approach, I'd have to remove the skip request each time I want to test the endpoint, then add it back when I run the collection.
• If I don't want to run a standalone request, I simply won't press the "send" button.

What you are saying is actually a very valid point. I think to break it down, there are two different requirements behind it.

Your Requirement: (I suppose)

• Skip Requests in Runner, because you wouldn't want to have them in the flow but would like to have them in your collection. Like let's say you have most requests you would do some "automated Testing", while keeping others in the collection for manual run.

My Requirement:

• Conditionally Skip Requests, when some preconditions are not met. Can have different reasons, like authentication missing or variables are not meeting some minimum quality gates. (Like I can only delete a entry, if I created one before)

However, honestly, I feel like the implementation you did with the bru.skipRequest() I would expect to meet my requirement. While for yours I would expect either to have a option in the runner to select the requests which you would like to run with some checkboxes or something or to introduce another function like bru.isRunner() to determine if the current call is executed within a runner. You could then use the bru.skipRequest() like this:

if(bru.isRunner()){
  bru.skipRequest();
}

In any case we both agree, that, if you execute a single request which is using the bru.skipRequest(); it should not run into an error and either skip the request (my expectation) or just run it (your expectation). If you cannot reproduce it it might be caused by my local installation, so if it is running in @sanjai0py 's installation or on some other machines without errors as well I guess it should be fine!

Does this make sense? Do you agree? Thank you so much already for all your efforts, I really appreciate your work!

[nikischin]

• On the overview of the runner requests the skipped request is not clickable before as we omit the status and the status was the clickable element:

I personally feel like it should be still clickable, but honestly, this is rather a new PR than actually your job to fix. Like I would expect to open the request when clicking on the name of it. Currently what it does, if you click on the status it shows the right part of the window for the request with the results, tests, ... which I would recommend to omit for the skipped requests as told earlier, so I really think it is ok as it currently is and should be worked on in another PR.

I opened a new feature request for this #3005 and a pull request #3006

Would really appreciate if we could get this PR merged, is there anything I could do to help you with the implementation? I am also not too familiar with the codebase, but in case you are stuck with something we might be able to figure out together.

[berlingoqc]

it's a bit related to that but I'm looking to add preconfigure scenarios for run feature.
Instead of just running the collection of the folder and having to skip some requests, just define the list of requests to be run with an extra variable. It's for integration test but this could help your case.

#2999

[nikischin]

@berlingoqc

Instead of just running the collection of the folder and having to skip some requests, just define the list of requests to be run with an extra variable. It's for integration test but this could help your case.

As I understand your PR, it's only for CLI?

Generally speaking as mentioned earlier there are two ways of how to manage selective runs:

• select the requests you want to run
• skip the request you don't want to run

Honestly, both have their benefits, however, I pretty like the idea of a skip condition in any case. I personally would most likely implement skip conditions for any variable not set to avoid spamming my server with malformed requests (which might generate unnecessary error logs).

[berlingoqc]

@nikischin

Yes it's only for cli now and if it get merged I'll add ui to configure and run it.

It's more to configure scenarios for integration test that are saved inside collections. I just mentioned it for visibility and because it could be useful in those case.

But yeah skipping is needed too

[JorgeTrovisco]

I close this PR because we need to break it down in smaller features to comply with "The pull request only addresses one issue or adds one feature."

1. Create a function to check on test level the context of the current run (single, runner)
2. Skip the request on test level - Current implementation was dedicated to skipping on runner level

I would appreciate if we could discuss the best approach before implementation, so that we don't need to refactor this code once more after the new implementation

[bstupid]

Bummer my requirement was only to skip with some logic in the pre script within runner

[nikischin]

1. Create a function to check on test level the context of the current run (single, runner)

I created a PR for this feature, extracted and modified from this PR. Would be happy if you would review #3105 and would be cool to get this merged.

For my understanding we could keep this PR reopened and address

2. Skip the request on test level - Current implementation was dedicated to skipping on runner level

with it.

My expectations would be like this:

• Skipping works on both runner and single requests.
• Skipped Requests are listed in runner like this: "Passed: XX, Failed: XX, Skipped: XX"
• A skipped request does not throw an error (neither safe mode nor developer mode)
• A skipped request does not has a HTTP Response status
• A skipped request does not show tabs Response, Timeline, Header or Tests
• Requests can be skipped in UI or CLI

Feel free to add some more expectations. I feel like this PR was really close already.

[JorgeTrovisco]

I will maintain this PR open expecting the completion of yours.

Meanwhile I will:

• Adjust the screen of the single call result to represent the skipped request;
• Understand and fix the error in safe mode;
• Understand how can this work in CLI without the need to explicit implementation that needs to be addressed in another PR (Would appreciate some help)

@ben-sai this approach will be much better because is able to address what everyone needs. (Both skipping in runner only, everywhere and conditionally base on any variable)

[JorgeTrovisco]

What do you think about this new screen to represent the skipped request?

[JorgeTrovisco]

• Adjust the screen of the single call result to represent the skipped request;

I think that is good at this point

• Understand and fix the error in safe mode;

Already fixed!

• Understand how can this work in CLI without the need to explicit implementation that needs to be addressed in another PR (Would appreciate some help)

Is there any guide like https://github.com/usebruno/bruno/blob/main/contributing.md to run the CLI version?

[nikischin]

I haven't tested in cli but in UI it works very well for both runner and single request, thank you so much!

[mangelco]

Thank you for your work on this! This feature is essential for our current project. Implementing this functionality will greatly enhance endpoint testing, and I believe many other users will benefit from it as well

[DumitruAndreea]

Hi! When this future will be available?