Repository navigation
Issues capturing output of algolia cli / running on headless systems #170
Description
A couple of issues spotted when running algolia CLI headless:
1 - important - using algolia cli for reporting from scripts
Seems like algolia CLI is a good component for no code integrations if this was fixed
psql -t postgres://user@pass:host.name/mydb -c 'select row_to_json(a) from my_data a' \
| algolia objects import my_poc --file - \
| tee /tmp/result.txt ; cat /tmp/result.txt && echo ===END==
results in this output on console and the empty file /tmp/result.txt:
===END==
I would expect to see something like the below in the file and console but it's empty.
✓ Successfully imported 9999 objects to my_poc 9.99999s
This one is less important but still significant
Shows that the CLI is written with some assumptions about what type of system it's running on. In this case a headless VM in the cloud:
$ algolia open cli-repo
exec: "xdg-open": executable file not found in $PATH
In this case where xdg-open is unavailable I'd expect the tool to echo the URL.
Activity
clemfromspace commentedon Jul 22, 2024
Hi @dr-kd and thanks for your detailed report.
For your first point, output messages of the
objects importcommand amongst others (objects delete, etc.) were not designed to be machine readable in the first place, and that's why we skip them if we detect a non-tty output.For most of those commands, the return code can be used to detect success / failure.
I am curious about your use case, your intent was to parse the success message and to extract information from it?
Second point: Looks like a bug, looking into it.
dr-kd commentedon Jul 22, 2024
Return code makes sense - in that manner I can run extra stuff in the pipe with some
&& [success command here] || [fail command here]- I just found the absence of output a little confusing and counter-intuitive as it's not the usual behaviour I'd expect to see. I would imagine if I was getting the output I'd be piping it straight into our opensearch dashboards analytics via syslog for reporting. And in that case there would be fewer moving parts and thus a smaller surface for failure rather than relying on extra&& ||type constructs.clemfromspace commentedon Jul 23, 2024
@dr-kd Understood 👍
Potentially, we could introduce a
FORCE_TTYkind of env variable, that would force messages output even if a non-tty shell is detected 🤔dr-kd commentedon Jul 23, 2024
I think a flag
--ttyor maybe--stdiomight be a better fit - then one's script has to explicitly point out the fact that it's a script with standard output handles at the time it is is told to run.clemfromspace commentedon Jul 23, 2024
Agreed on the flag.
Just a gotcha: This thing could not play nice with the progress indicators / loaders that the CLI currently have. Outputting those to something else than a terminal might wield weird results. We will have to check if we can avoid forcing tty on those.
anjakunkel commentedon Apr 24, 2025
I seem to have (had) an related issue. I'd like to use objects import inside our CI/CD, so non-interactive. For that, I've been trying to get https://www.algolia.com/doc/tools/cli/get-started/examples/#copy-indices-between-applications to work. While it runs fine on terminal, it silently does nothing on CI/CD. As I've found this thread, I changed the command from
algolia objects browse INDEX -p PROFILE_1 \ | algolia objects import INDEX -p PROFILE_2 -F -to
algolia objects browse INDEX -p PROFILE_1 \ | algolia objects import INDEX -p PROFILE_2 -F - && echo "✅ Imported objects" || echo "❌ Failure (objects)"and only this made it work on non-tty, too.Is this another use-case for your list, @clemfromspace ?