CLI script interaction

[jaw]

Hi,

some suggestions / questions.

Idea 1
when launching ntlite.exe from CLI, the program launches the GUI and then the control is given back to the terminal.
In Unix speak, the process forks.
This makes me wonder how I shall integrate this in a scripting/CI environment.

Option 1:
Is there a flag to ntlite.exe or a way that the CLI calling process can block until all tasks have been performed?
Maybe this would also require the flag /Exit:AfterApply to be present so the program is not expected to linger after work is done.

Option 2:
Is there a flag which can check if ntlite.exe is running?
If ntlite would return 1 or 0, that might be enough.

Option 3:
Repeatedly use powershell process query tools to check if the program is running:
Get-Process -name ntlite
I can of course do this, but this option seems rather clunky.

Idea 2
Is it possible to have NTLite not open up a GUI window and instead log its progress directly to stdout?
This would make it easier to launch it with say, Ansible which connects via SSH.
This is also how most CI systems - github runners to name one - works.

 

[jaw]

Actually, seems like Idea 1 is moot - it does block when called from Python
I experienced it "fork" when calling it manually from Powershell.

For Idea 2, I could just make sure the log dir is empty before and then harvest what has shown up in there.

 

[nuhi]

Thanks for the detailed write-up, both points are fair.

On Idea 1: NTLite is a GUI program, so PowerShell and cmd return to the prompt right away instead of waiting for it.
Python's subprocess waits on the process handle, which is why it blocked there.
In PowerShell, wait explicitly and read the exit code:

$p = Start-Process "C:\Program Files\NTLite\NTLite.exe" -ArgumentList '/Path:"D:\Image" /Load /Index:1 /Preset:"MyPreset" /Apply /Exit:AfterApply' -PassThru
$p.WaitForExit()
$p.ExitCode

With /Exit:AfterApply the process exits when the job is done, 0 on success and non-zero on failure.
Each action also writes a "NTLite: <verb> SUCCESS" or "FAILED" line to the log.
Check the exit code rather than parsing the log, since the log is only complete once NTLite has exited.

On Idea 2: there is no headless mode today.
A command-line run drives the normal NTLite window, and genuine errors or questions show as dialogs instead of being silently skipped.
So for now it needs a logged-in desktop session; over SSH or on a runner with no visible desktop, a dialog nobody can see would stall the run.

Your post pushed this up our list.
I'm planning a small console companion for scripting that waits for the job, streams progress to stdout, returns the exit code, and lets you answer NTLite's questions right in the console (with a clean non-zero exit when nobody is there to answer, e.g. in CI).
No date yet, I'll update this thread when it lands.

 

[jaw]

Cool, thanks!

Yes, I ran into one of the dialogs that required an "OK". Solution for that one is to remove files that cause those conflicts etc (re-unpack the ISO in this case).

Just to put this in perspective - the thing I'm working on is automatically building a weekly windows VM image for CI workers.
Ideally also triggered by a CI job. (Github's weekly builds for example.)

(Github actions syntax for weekly job)
on:
workflow_dispatch:
schedule:
- cron: '0 4 * * 5'

Thus, if this process can be fully automated and headless would be truly awesome. Then each week's results (stdout) will be recorded in the nice github actions GUI, and one can even store artefacts (ISOs) there such as ntlite logs etc.

So in that context, optionally supplying an default answer to otherwise notify-user questions would be awesome. Of course, hard errors are what they are and program should abort with exit code=1.

If you want early feedback/iteration I'll gladly help debug / experiment.