An easy way to reuse requests

[jcamiel]

(Imported from original discussion @spaceaardvark)

I don't think there's a way to do this yet, but it would be great to have an easy way to reuse a request in multiple .hurl files.

For example, suppose sign-in.hurl signs in a test user in and extracts their name and email from the response. I would like to reuse that request in test-1.hurl and test-2.hurl without having two duplicate everything in sign-in.hurl.

[fabricereix]

That could be useful but we are also afraid that it will bring a lot of other issues: error reporting, imports cycles,...

For the time-being, we recommend to generate the Hurl files (with scripts) when we need to reuse common requests.
But we understand that it not might be the best for everyone.
We still need to think about it.

[nikeee]

Do hurl files share the same session when passed as a parameter? If so, one could just do hurl login.hurl action.hurl, with login.hurl capturing the necessary tokens.

[fabricereix]

Each Hurl file has each own session.
You could use the standard input to get the same session

cat login.hurl action.hurl | hurl

[lepapareil]

@nikeee perhaps this #115 will meet your needs :).

[MissingHandle]

we are also afraid that it will bring a lot of other issues

the sign of a successful project?

[nikeee]

For the time-being, we recommend to generate the Hurl files (with scripts) when we need to reuse common requests.

Today, I've refactored our scripts that generate the hurl files. Before, it was a bash script that outputs hurl contents (by using cat on the parts). Didn't like that approach.

Instead, I've refactored it to use a "preprocessor" that replaces #include directives with the respective file contents. It also resolves symlinks and detects cyclic dependencies. If anyone needs it, you can find it here:
https://gist.github.com/nikeee/748301705d3ed53b6b8776fba8748a9b

The file sill has valid hurl syntax, because # is also the start of a comment. So no syntax highlighting is broken:

#include actions/login-user.hurl

POST http://localhost:8080/contact
[FormParams]
email: someone@example.com
subject: Test
token: {{xsrf-token}} # from login-user.hurl

This seems to work pretty good for us at the moment.

[fabricereix]

Thanks @nikeee for sharing!
it's very clean and readable.
I think it will be interesting to add it in our contrib folder.

[nikeee]

If this is something you'd be interested in, I'd file a PR for the contrib folder (and make it a bit more resistent; for example, trailing whitespace does not work yet).

---

While implementing and using that, I realized that some users might want to add parameters to scripts or override variables respectively.

For example, you can call hurl and set a variable that is used in the hurl file:

hurl --variable host="example.com" a.hurl

THis might be useful when including/re-using hurl files. I modeled a workflow where there are two users, with two different sessions. Depending on the action included, it might make sense to override variables in the includes:

POST /login
[Captures]
user_cookie: ...

POST /admin-login
[Captures]
admin_cookie: ...

#include post-comment.hurl --variable cookie={{user_cookie}}

#include delete-comment.hurl --variable cookie={{admin_cookie}}

(the syntax is only for demonstration of the idea, not an actual proposal)

This is not supported in the preprocessor script above as I managed to get around the need for that (yet).

[fabricereix]

Yes, you can file a PR in contrib/preprocessing folder.
We like generating source files in general. We treat the generated sources as normal source files, namely committed in the repository. With Hurl, they will be the one to look at when an error occurs.
Do you also commit them?

[rochacbruno]

Duplicate #2110

[dodalovicgran]

Each Hurl file has each own session. You could use the standard input to get the same session

cat login.hurl action.hurl | hurl

While this works, once you get an error, you have no clue where it comes from.