Container: add withFocus, withoutFocus

[vito]

fixes #5156

extend type Container {
  """
  Indicate that subsequent commands should be featured more
  prominently in the UI.
  """
  withFocus: Container!

  """
  Indicate that subsequent commands should not be featured
  more prominently in the UI.
  This is the initial state of all containers.
  """
  withoutFocus: Container!
}

You would typically use this to mark the command that accomplishes the primary goal of the pipeline, such as the command that runs your tests. You can also just splice it into a call chain for troubleshooting.

func GoGenerate(
	ctx dagger.Context,
	base *dagger.Container,
	src *dagger.Directory,
) *dagger.Directory {
	return base.
		With(GoCache(ctx)).
		With(Cd("/src", src)).
		WithFocus().
		WithExec([]string{"go", "generate", "./..."}).
		Directory("/src")
}

Depends on vito/progrock#8

Here's how it looks in its current form:

[vito]

@sipsma @shykes I think this is ready for consideration now. The DX feels pretty decent after dogfooding for a while.

Summary of changes:

• Add withFocus and withoutFocus, currently only implemented for Container and only respected by withExec but we could perhaps generalize this to any kind of operation that might show up in the DAG.
  • Unfortunately the implementation is a little hacky (it relies on a [focus] vertex custom name). We're unable to leverage much of Progrock here because we still rely on events coming out of Buildkit for exec logs.
• dagger do respects focus by default, and you can show everything with --focus=false.
• dagger run does not respect focus by default - it shows everything, and has a --focus flag.
  • I'm not sure if this is necessary, but the thinking is that dagger run is more low-level so debugging is more useful there.

Still open to other suggestions though. Also open to TUI suggestions. I can keep noodling on that.

[sipsma]

Not a blocker but it doesn't feel ideal that this would change the ID. In the context of Zenith this matters more since once we support Container/Directory/etc. as input args to entrypoints, the cache will be invalidated just by changing Focused, which is more of a UX concern.

However, there's a few other things like this already (e.g. pipeline labels), so this doesn't really make it any worse. We'll need to come up with some generic way of dealing with all these at some point in the future.

If there's some utterly trivial different approach to this that doesn't involve putting it in the ID, then I'd say go for it right away, but I'm guessing there isn't anything obvious yet, in which case all good for now.

[vito]

Yeah I'd also like to find a generic alternative to this pattern. Using queries for "meta" operations like this also blew up in my face when I was trying to come up with a proposal for generic query memoization (as an approach to dependency pinning):

https://github.com/dagger/dagger/pull/5420/files#diff-7340b8a6d2c5b52c935f75ec72038d28b8c606323ea41bd29ced4b521eae7761R115-R118

(Quoting in case that link breaks with future pushes:)

• TODO: We'll need some way to prevent meta-queries like pipeline() and
  memoize() from becoming part of the cache key. If we can't come up with a
  better idea, we could always just reserve the words and drop them from the
  query path during memoization.

I think this is OK for now since it's a drop in the bucket compared to storing pipeline info (which also massively inflate the ID values, as I'm sure you're already aware 😁).

[sipsma]

nit: would it be more technically correct and explicit to say subsequent withExecs instead of commands?

withExecs is probably a very awkward adverb(?), so maybe just subsequent execs?

Just don't want to create ambiguity around the term "commands".

[vito]

wdyt of "operations"? Right now it's only execs, but we might want to support something like foo.WithFocus().Export(ctx) too (assuming Export does something useful like printing filenames as it exports).

[sipsma]

Yeah operations sounds good!