BYOC provider should track in-progress work and update status

dotnet / arcade

Tools that provide common build infrastructure for multiple .NET Foundation projects.

MIT License

664 stars 339 forks source link

BYOC provider should track in-progress work and update status #2383

Closed mmitche closed 5 years ago

mmitche commented 5 years ago

BYOC should track in progress helix jobs and report status to Azure DevOps. Informational updates will not yet be shown to the user, but fail/warning messages will. Should update every so often.

markwilkie commented 5 years ago

@Chrisboh - thoughts on where this should live? Is it part of the visualization??

mmitche commented 5 years ago

@markwilkie Unrelated to visualization, and the work here will not immediately have benefits for the user until AzDO completes their UX work. No idea where it lives but we need to do it.

Chrisboh commented 5 years ago

It sounds like nothing is critical for this right at this moment. Lets talk more about this in Triage as I would like more context about how to think about the interface between AzDo and us.

markwilkie commented 5 years ago

@Chrisboh - which business priority should this live under do you think?

Chrisboh commented 5 years ago

Is there anything that we can do about this right now? I am only guessing but doesn't AzDo need to do work before we can make this work in any meaningful way?

mmitche commented 5 years ago

@Chrisboh Sort of? Depends on what info you want to present. Basically:

If it's info level (e.g. this job is waiitng, queue is X deep), then they need to do work
If the Helix job fails after it is submitted, then we could tell AzDO today, instead of just having it wait around forever, and AzDO will show the feedback on the job console.

Both cases are pretty similar in terms of implementation (check status of jobs). One can be implemented today, and one requires further work from AzDO.

ChadNedzlek commented 5 years ago

This doesn't really belong in this epic. This isn't a metric (nothing in this issue is going to report a KPI to anyone), especially if it requires changes to Azure DevOps API surface. And it definitely correspond to any of the business goals of the KPI epic.

ChadNedzlek commented 5 years ago

Popping out to triage to figure out what to do about this. It sounds like we need changes to AzDO for anything meaningful here, and I don't want this epic to just linger forever.

mmitche commented 5 years ago

@ChadNedzlek AzDO now shows the updates (in the new multi-stage pipeline UI), so we just have to track our helix work and provide periodic updates.

markwilkie commented 5 years ago

@chcosta - is this now sorted?

chcosta commented 5 years ago

Depends on the scope of this issue. My understanding is that if this is just about reporting Helix pass / fail back to the AzDo UI, then yes, this is sorted. AzDo also provides the ability to report back progress level info (ie, 5% done, 30% done, etc...), we're not utilizing this feature anywhere and I imagine that it's going to come across like every install dialog we've ever seen (installing 0 - 99% takes appx 30 seconds and the last 1% takes 10 minutes).

Also, as Mitchell mentions, this isn't currently possible.

If it's info level (e.g. this job is waiitng, queue is X deep), then they need to do work

markwilkie commented 5 years ago

Ok - closing unless somebody actually needs this.

cc/ @Chrisboh