Add a command structure to Go driver

[zjrgov]

🎫 Addresses issue: https://github.com/GSA-TTS/devtools-program/issues/199

Foundation for calling different functions of the cf-driver executable

🛠 Summary of changes

• Adds cobra module to help manage commands
• Adds some "documentation" to the commands, mostly lifted from GitLab's custom runner docs and meant for updating as the actual commands are getting written.
• Removes the stand-in stuff that in main.

📜 Testing Plan

How would a peer test this work?

• go run main.go will execute the top-level command
• It should tell you about drive, which is the main command to be fed to gitlab-runner.
• It should run subcommands like go run main.go drive prepare
• Each command & subcommand should return something and should work with the -h or --help flag.

👀 Screenshots and Evidence

Here's an example of what some of the output looks like

This is CloudFoundry Driver for the GitLab Custom executor.

The gitlab-runner service should run cfd with it's "drive" subcommands,
e.g., "cfd drive prepare".

Usage:
  cfd [command]

Available Commands:
  drive       Drive stages requested by gitlab-runner's executor
  help        Help about any command
  completion  Generate the autocompletion script for the specified shell

Flags:
  -h, --help   help for cfd

Use "cfd [command] --help" for more information about a command.

[rahearn]

nice framework, and I appreciate the docs being in-line and having links a ton

[rahearn]

[question] - the docs mention cfd but when I run make build I get a cf-driver executable. Should those be consistent? If something needs to change I do like the shorter version more.

[zjrgov]

Good catch, I haven't been using the actual executable much & didn't think of it.

[rahearn]

[question] is there a planned use for calling drive by itself ever? Feels like we could attach its subcommands directly to root.go instead

[zjrgov]

My thinking was to segregate the gitlab-runner stage commands so that there was room in the future to add other stuff to the executable. I'm not sure that would necessarily happen—I was imagining some kind of administrative / configurative command could come in, a doctor or who knows. It could be that that never happens, but given that nobody is actually going to type these often, it seemed pretty low-cost?

I'm not super attached to the idea though.

[rahearn]

That makes sense, and yeah, since these are basically never typed I'm not opposed to the extra characters.

[rahearn]

ooooh - we should replace the current CUSTOM_ENV_PRESERVE_* behavior with a long (1 hour?) timeout instead of just skipping

[zjrgov]

Mm yeah that would be good. An hour feels long to me, but I'm supposing it must not to you?

[zjrgov]

Oh I misunderstood you when I first read this and thought you were just talking about adding a timeout to make sure broken jobs get cleaned up.

How are you thinking this would work? We could put something like a long sleep in the run step? It does seem like an easy way to take care of at least half of #34.

[rahearn]

Ideally it'd be something like what circleCI does, which is 10 minutes + whatever time you're ssh'd in to the runner to do your debugging. 1 hour was assuming that we wouldn't be able to have a dynamic timeout like that.

[rahearn]

How are you thinking this would work?

🤷🏻 this might also be a misinterpretation of the cleanup_exec_timeout docs that triggered this whole thread. I was thinking that we could set that config and gitlab would take care of not calling cleanup right away, but that's probably wrong.

In any case, it was a thought for 34 or similar, not this PR

[zjrgov]

I think I misunderstood it… I was thinking it was a timeout on how long it would wait to kill run, but it's a timeout on how long it will wait to kill cleanup. Every stage but run has one of the timeouts, and run's time is managed in GitLab's settings globally and per runner.

But I do think we could use it to do the debugging PRESERVE's better:

• set a long timeout on cleanup, just to override a shorter default if there is one
• set a sleep that's a bit shorter than the timeout
• do the regular cleanup after the sleep