-
Notifications
You must be signed in to change notification settings - Fork 615
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Send Progrock updates to Cloud #5297
Conversation
c007389
to
00aa067
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ready for review! Did a review of my own and left some comments below, hope it helps.
Name: pipelineName, | ||
}) | ||
ctx, subRecorder := progrock.WithGroup(ctx, pipelineName) | ||
ctx, subRecorder := progrock.WithGroup(ctx, fmt.Sprintf("from %s", addr), progrock.Weak()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Marking a pipeline as "weak" allows us to differentiate these implicitly-added pipelines from explicit user-configured ones.
Pipeline pipeline.Path | ||
} | ||
|
||
func (r PipelineMetaResolver) ResolveImageConfig(ctx context.Context, ref string, opt llb.ResolveImageConfigOpt) (digest.Digest, []byte, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is handled by (core.GatewayClient).ResolveImageConfig
now.
@@ -1110,7 +1079,7 @@ func (container *Container) WithExec(ctx context.Context, gw bkgw.Client, progSo | |||
// create /dagger mount point for the shim to write to | |||
runOpts = append(runOpts, | |||
llb.AddMount(metaMountDestPath, | |||
llb.Scratch().File(meta, pipeline.CustomName{Name: "creating dagger metadata", Internal: true}.LLBOpt(), container.Pipeline.LLBOpt()), | |||
llb.Scratch().File(meta, llb.WithCustomName("[internal] creating dagger metadata")), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the one spot where we want to mark a Buildkit vertex as "internal." We don't need to shove the whole pipeline path in there anymore, so I swapped it out for a [internal]
prefix, which gets stripped off and turned into internal: true
during the Buildkit => Progrock conversion.
@@ -256,18 +256,15 @@ func (dir *Directory) WithNewFile(ctx context.Context, dest string, content []by | |||
|
|||
parent, _ := path.Split(dest) | |||
if parent != "" { | |||
st = st.File(llb.Mkdir(parent, 0755, llb.WithParents(true)), dir.Pipeline.LLBOpt()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't need to pass pipeline info to Buildkit anymore; group <-> vertex membership is handled by core.GatewayClient
.
@@ -64,9 +64,6 @@ func loadRootLabels(workdir, engineName string) []Label { | |||
return labels | |||
} | |||
|
|||
// ServiceHostnameLabel is annotated on all services started by Dagger. | |||
const ServiceHostnameLabel = "dagger.io/service.hostname" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This originally existed so we can detect service vertices and treat them differently, which shouldn't be needed once we convert it to the gateway. I don't think this ended up being load-bearing, so just removing it along the way.
@@ -383,58 +334,6 @@ func eventsMultiReader(ch chan *bkclient.SolveStatus, readers ...chan *bkclient. | |||
} | |||
} | |||
|
|||
func uploadTelemetry(ch chan *bkclient.SolveStatus) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This has moved to telemetry.Writer
.
22caf86
to
3498067
Compare
This is an incremental step that maintains compatibility with the Dagger Cloud API. Groups are mapped to pipeline paths. (TODO: pipeline descriptions are currently droped.) Vertex <-> Group membership is handled client-side; an Op will be emitted for every group membership. Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
this was copy-pasta from Bass, not intended to be preserved in Dagger Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
this is used for engine logs - need to dedupe these, or maybe use one in the other Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
'weak' pipelines are ones that Dagger automatically adds, or a Buildkit frontend adds via a ProgressGroup. They are treated differently from user-specified pipelines. Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
Too difficult to figure out many-to-many vertex <-> groups in the frontend. This is much simpler for now. Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
* remove JournalWriter (unused) * remove internal/engine/journal/ (outdated) Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
* add telemetry.Pipeliner for tying vertices to pipeline.Paths Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
trivial now that there's telemetry.Writer Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
We're no longer putting this information into Buildkit, so the console output no longer shows pipelines and such. To be clear, this format was always a bit janky, often resulting in things like blank vertex names. These tests can be brought back once Progrock has a proper console output format. Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
this was a temporary hack to show the Dagger Cloud URL in the TUI. will figure this out in a separate PR. Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
no need to tie this 100% to Buildkit events, in case we want to create any other vertexes Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
* --silent no longer configures console output format, which was frankly confusing. --progress has been added instead. * removed buildkit console format; we are now 100% Progrock! * show Cloud URL and engine name in TUI Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
the Progrock socket should always be available, so this is pretty pointless anyway Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, super minor comments/questions
telemetry/telemetry.go
Outdated
t.mu.Lock() | ||
defer t.mu.Unlock() | ||
if t.token != "" { | ||
// no token; don't send telemetry |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this comment supposed to be outside this if
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed! Not sure what happened here, probably inverted the conditional or something.
if !silent { | ||
if progress == "auto" && autoTTY || progress == "tty" { | ||
if interactive { | ||
return interactiveTUI(ctx, engineConf, fn) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we not set the EngineName
and CloudURL
callbacks for the interactive TUI? If so, is that just an oversight or is it because we'll need more updates to display those in the interactive tui? Not a big deal either way, just checking
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs more updates; will probably do it in another PR as this one's already grown quite a bit.
telemetry/pipeliner.go
Outdated
if group.Parent != nil { | ||
parentPath, found := t.pipelinePaths[group.GetParent()] | ||
if found { | ||
path = append(path, parentPath...) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
extreme nit, probably separate issue if one at all: is there harm in changing pipeline.Path
to be type []*Pipeline
? It just looks like we are using quadratic memory here by re-copying each parent path, which I guess could plausibly matter in extreme scenarios with many long pipelines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done! I don't think this matters too much since it only happens when a group starts or finishes, and the largest chunk of data (Labels
) is already by-reference, but it's a tiny tweak and every bit helps.
pretty tiny change that should reduce some memory pressure, since each of these values never change. (this likely has very little actual effect, just seems sensible.) Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
This is an incremental step that maintains compatibility with the Dagger Cloud API:
everythe first group membership as soon as both pieces of information are known.In the long run we might want to store groups as first-class entities in Cloud to aid with querying and knowing the actual start/end of a pipeline, but that's a bigger lift.
It also:
cmd/{upload-journal,dagger-graph,otel-collector}
) - though I fully admit I haven't tested theseFixes DAG-1087