Add custom boot command that waits for text to appear

[torarnv]

Using <wait "string"> or <wait "(some|regex|here)"> allows installing macOS without having to specify hard-coded timeout waits such as <wait10s>.

[torarnv]

Missing docs for new wait command, will add after initial feature review

[torarnv]

This allows e.g:

diff --git a/macos/macos.pkrtpl.yaml b/macos/macos.pkrtpl.yaml
index bed5e73..305532e 100644
--- a/macos/macos.pkrtpl.yaml
+++ b/macos/macos.pkrtpl.yaml
@@ -1,14 +1,8 @@
-wait_for_boot:
-  # Wait for VM too boot
-  # FIXME: Ideally there would be some way to wait for the first
-  # non-black frame from the VNC server.
-  - <wait60s>
-
 install_macos:
-  # Hello, Hola, Bonjour, etc.
+  - <wait "Get Started">
   - <spacebar>
-  - <wait5s>
+  - <wait "Language">

[torarnv]

Is the builder not a macOS machine?

[edigaryev]

Hi @torarnv 👋

This is a pretty cool use of Apple's Vision framework.

Have you considered submitting this to packer or packer-plugin-sdk directly?

This way:

1. Not just Packer Plugin for Tart could benefit from this, but literally all existing packer plugins, assuming that on non-macOS platforms something like github.com/otiai10/gosseract could be used

2. <wait> syntax could be extended natively, without performing any hacks on Packer Plugin for Tart's side and yielding correct documentation

[torarnv]

Thanks @edigaryev!

I did initially considered building this feature into packer-plugin-sdk's bootcommand package directly, but as this was a quick hackathon project, where my focus was to get something workable for packer-plugin-tart (scratching my own itch), I deferred that approach.

An upstream feature in packer-plugin-sdk would make sense, but one challenge there is that bootcommand has 3 different backends (VNC, USB, and PC-XT), and from what I can tell the boot commands are backend-agnostic. Adding the feature in the SDK would inevitably diverge the feature set, which I'm not sure is acceptable.

Using github.com/otiai10/gosseract would be an option, but would add more dependencies compared to the fairly straight forward use of the built in Vision.framework.

One possible upstream improvement would be to teach bootcommand to extend the grammar, so that we don't need regex-based logic to add new commands, but I sadly won't have time to dive into that.

I'm still testing this feature on my nightly builds, so we can hold on on merging for now. Let me know if you have other concerns though!

[torarnv]

I guess we need to move the lint and build to a macos_instance? Are there any predefined Cirrus images or rules that include the golang (lint) toolchain?

[torarnv]

Missing docs for new wait command, will add after initial feature review

Done

[torarnv]

@edigaryev @fkorotkov thoughts? 🙂

[edigaryev]

I guess we need to move the lint and build to a macos_instance? Are there any predefined Cirrus images or rules that include the golang (lint) toolchain?

Something like this should do: d02016e.

[torarnv]

Thanks for the reviews @edigaryev, will push an update soon. And thanks for fixing the CI bits to run on macOS :)

[edigaryev]

And thanks for fixing the CI bits to run on macOS :)

You should probably rebase against main to get it working.

[hisaac]

Howdy @torarnv, @edigaryev. Where are things at with this PR? I'm very eager to use this functionality. Is there anything I can do to help move things along?

[torarnv]

Hey hey @hisaac! I've been swamped, but picking this up now, will push a new PR soon!

[hisaac]

Sounds great. Let me know if you'd like any help testing or anything. I should have some time in the next couple weeks to help out if needed.

[torarnv]

@hisaac Please test the latest version, thanks! 😄

[torarnv]

@hisaac @edigaryev you may find hashicorp/packer-plugin-sdk#293 convenient as well. If it takes time to merge upstream, perhaps we can go replace the SDK with my fork?

[hisaac]

@hisaac @edigaryev you may find hashicorp/packer-plugin-sdk#293 convenient as well.

Love this!

[edigaryev]

@hisaac @edigaryev you may find hashicorp/packer-plugin-sdk#293 convenient as well. If it takes time to merge upstream, perhaps we can go replace the SDK with my fork?

Nice addition for Packer + macOS usability indeed!

Let's just see how fast it gets reviewed/merged and then go from there.

[hisaac]

ok I've tried to figure out how to test this but am not having any luck. How do I point to this branch in my Packer template so I can test the changes?