Adapt according to suggestion and rework query and query sample presentation

Rebase

Closed by 8e125f1

Adapt according to last irc discussion -> use --preset

Expose the new subcommand

Amend according to discussion and fix tests

• cli.add_forge_now: Open register-lister with sensible defaults
• cli.add_forge_now: Rework according to review

Fix

Fix

Adapt somewhat according to review (let jenkins builds stuff) [1]

Neat simplification indeed, congrats \m/.

For --staging, we just want to create a single oneshot full listing task.

Why bother with a full listing?

Since we now got the means to limit the listing, i'd use it. That's a faster feedback
loop and without stressing twice the upstream forge (one round for staging and another
for production at a relatively small intervals of time).

Maybe I need to configure the default to a more sensible defaults though. Like 3 pages
with 10 results (so that we can see that the pagination works too). Currently it's a tad
small (1 page of 15 or something).

Sure, that's what I meant: for staging, schedule a oneshot full listing task, but with the limiting and "origin disabling" options ("full" as opposed to "incremental")

So, I don't think we want to have to remember if there's full or incremental versions
of the lister.

Adapt according to suggestion

d'oh at your suggestions, you're totally right!

I was sold on the description!

Adapt according to irc sysadm discussion

• Improve implementation according to suggestion
• Rework commit and diff message

Dropping --tablesample 1 helped...

yeah, well, it does help to remove the echo in front of the instruction...

num num num... i did not mean to push that one.
Please, tell me if i need to revert it...

Does it seem like we're going to use these arguments in another caller of grab_next_visits?

That's a good question. I think not.

Maybe we would, actually. For instance, it might make sense to use these options to give different scheduling weights for github/gitlab/... origins in the recurrent visit scheduler.

Fix tests

Drop --lister-uuid flag to the benefit of using --lister-name and --lister-instance-name

Does it seem like we're going to use these arguments in another caller of grab_next_visits?

LGTM, been a while since I read java code, so verbose (especially for iterations).

Amend commit message and fix tests

Adapt according to suggestion (still trying to determine why the build fails)

To adapt according to suggestion (already on it).

ok then!

Good idea but you need to update that conditional.

just something i don't get in the test, as per my question inline.

one question to team inline.

Landed through 23b3255c3cbd3deed8c7865ae1d1ca7045bdd386

Makes sense.

What is it going to be used for?