Group output if running under GitHub Actions

[javierhonduco]

A small but very useful thing to do when the output in CI systems is very large is to group parts of the output in sections that can be unfolded by the user. In GitHub Actions this can be accomplished by surrounding the output with ::group:: and ::endgroup:: (see the docs). The GITHUB_ACTIONS environment variable is set if running in this CI system.

If nobody implements this in the next few days and Daniel is happy with this change I will put a PR when I have some spare cycles 😄 .

[danobi]

Makes sense to me! Originally I was thinking that kind of stuff would go into https://github.com/danobi/vmtest-action. But if that action is not actually useful feel free to put it in vmtest.

[danielocfb]

Introducing a group for boot output would be fine, but I feel like the script output should just manifest untouched. I'd also very much prefer this functionality be implemented in the corresponding action.

All that being said, if you compile a minimal kernel without printk support, there is not much output to begin with :P

[javierhonduco]

Introducing a group for boot output would be fine, but I feel like the script output should just manifest untouched.

Was thinking of implementing this in Rust, not in the init script, would that be ok by you?

I'd also very much prefer this functionality be implemented in the corresponding action.

While I think having all the GitHub specific functionality in one place would be ideal, I am currently using vmtest without an Action and I would prefer to keep it this way if possible.

[danielocfb]

Introducing a group for boot output would be fine, but I feel like the script output should just manifest untouched.

Was thinking of implementing this in Rust, not in the init script, would that be ok by you?

Of course. My main worry is that we end up putting GitHub Action specific logic into this crate, which really shouldn't have any knowledge of GitHub Actions.

But what I meant by my comment is that there are conceptually two "types" of output: the kernel's boot up stuff (+ some vmtest messages) and then whatever output it is that the user's command emitted. I'd prefer if we left the user's command's output untouched.

Off the top of my head, perhaps the best solution would be to have the means to redirect either of the two outputs, e.g., by providing file descriptors to use. This would be a generic approach that you could hook into to insert ::group:: markers as and where needed, at the call site. Just a thought.