Re-use probes support

Question

Re-use probes support

jimaek opened this issue a year ago · 19 comments

The API can support running tests from the same probes as some previous measurement by providing the ID. jsdelivr/globalping#453

Need to figure out the best way to implement it in the CLI.

Here is my idea:

Document the feature in README and CLI docs
Add --reuse parameter. The CLI will store in some env var the ID of the last measurement and with that parameter will automatically get and reuse the last ID. If there is no ID stored it will just run a fresh measurement. see below

@MartinKolarik thoughts?

Answer 1 · 2023-12-08T12:41:09.000Z

First, the simple part: document that the ID can be passed to the --from parameter. That's something you can do even if you got the ID from some other source: ping google.com --from zFUra8K0lGO3vqBn

The history idea seems cool, but might need to allow more than just one ID to be useful. I suggest keeping the --from parameter for this but using bash-like numbered entries:

--from !1 # reuses first ID from the session
--from !2 # reuses second ID from the session
--from !! # reuses the most recent ID from the session

This way, people will most likely do !1, but then, when they need to add in a second set, it naturally works with !2. Note that the history should be stored per session only, and only commands where the location is explicitly set should create new entries - if I run !! five times, there should still be just one history entry.

Answer 2 · 2023-12-08T13:49:54.000Z

Your version sounds good for advanced users but I think we need a simple version of it for people unfamiliar with bash variables.

How about we combine both ideas?

Answer 3 · 2023-12-08T14:05:48.000Z

I wouldn't mind having an extra way for the --from !! case, but trying to think of a better name. --reuse doesn't seem as clear and fluent as our other options. Would --from previous be simple enough?

Answer 4 · 2023-12-08T15:53:32.000Z

Ok sure, lets add also from previous and from last

Answer 5 · 2023-12-08T16:09:00.000Z

So numbered references as I described + previous/last and no --reuse ?

Answer 6 · 2023-12-08T16:10:58.000Z

Yep sounds good to me

Answer 7 · 2023-12-12T10:45:51.000Z

@jimaek @MartinKolarik
1/ I'm not sure I understand what is meant by "the session" here ? I don't think the CLI saves any state or history at the moment
2/ I don't think the syntax --from !1 will work, that syntax is already autoexpanded by bash. If I try to run globalping ping google.com --from !1 and the command corresponding to number "1" in my history is ls /tmp, the resulting command will be globalping ping google.com --from ls /tmp

Answer 8 · 2023-12-12T10:59:35.000Z

Correct, part of the task would be to save the measurement IDs of tests in an env var to allow the CLI on the next run to re-use it if needed
@MartinKolarik what do you suggest? We can just keep the last/previous syntax

Answer 9 · 2023-12-12T11:04:22.000Z

@jimaek I don't think the Go program can set an env variable that will be accessible by future runs of the CLI. I think we would need to create a file on disk and save the data there.

Answer 10 · 2023-12-12T11:19:45.000Z

Why not? e.g. https://gobyexample.com/environment-variables

We also plan to use something similar to set a future API key.

Answer 11 · 2023-12-12T11:28:03.000Z

@jimaek
Environment variables set from inside a process are only available inside that process execution, they are not available for other processes or for future processes of the same program

Answer 12 · 2023-12-12T13:58:38.000Z

@jimaek I don't think the Go program can set an env variable that will be accessible by future runs of the CLI. I think we would need to create a file on disk and save the data there.

Yes, a file in %tmp%. I think using the parent PID + start time for the filename should work well to identify a terminal session, but you might find some other approaches too.

I don't think the syntax --from !1 will work, that syntax is already autoexpanded by bash. If I try to run globalping ping google.com --from !1 and the command corresponding to number "1" in my history is ls /tmp, the resulting command will be globalping ping google.com --from ls /tmp

Indeed, we could also go without a prefix character or choose a different one, will comment more later.

Answer 13 · 2023-12-15T16:03:19.000Z

Indeed, we could also go without a prefix character or choose a different one, will comment more later.

Let's allow:

@1, @2, etc to mean "first", "second", etc in the current session
~1, ~2, ... to mean "last", "second-to-last"
previous/last as an alias to ~1

Answer 14 · 2023-12-21T19:14:48.000Z

Hi @MartinKolarik
~ gets expanded by bash, maybe we can go with @-1 @-2 for last, second to last etc?

Answer 15 · 2023-12-21T19:29:54.000Z

~ gets expanded by bash,

Indeed but ~1 etc only gets expanded if you use pushd in the current session; otherwise, it doesn't expand, so it might be fine? And of course, you can still quote it if needed. @jimaek wdyt?

Answer 16 · 2023-12-21T19:31:41.000Z

It's true the +/- approach is often used in CLIs as well so I'm not strongly against, just ~1 would generally be easier to type.

Answer 17 · 2023-12-21T20:51:59.000Z

I vote for -1, it's safe and makes logical sense for users

Answer 18 · 2023-12-21T20:54:23.000Z

But without @. Just -1, -2... or previous/last

Answer 19 · 2023-12-21T21:00:39.000Z

But without @. Just -1, -2... or previous/last

No, that makes no sense, as primarily we have @1, see #79 (comment). For negative numbers, it's either @-1 or ~1 with the caveat it doesn't play nicely with pushd. Also, note that the positive variant is more important, I expect people to primarily use @1