You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When analyzing the results of an experiment, it can be easy to get lost in a build scan and not be sure whether it was the first or second build of the experiment. Often, the best way to check is by assuming from the performance of the build itself or navigating back to the summary view. It would be more concrete to capture this metadata as a tag or custom value so that it would be clear.
The text was updated successfully, but these errors were encountered:
A note on the design while I'm thinking about it: Using a custom value will show up as a difference in the build scan comparison, but a tag will not.
While that is true, I would find it easier to work with in the comparison if it's tag, since it shows up at the top with the rest of the build header in task inputs comparison for example. That way you're sure which build is which on that page without needing to jump to the custom values view.
I was also advocating for a tag when I wrote that. A custom value means there will always be a difference between the builds, which could be misleading.
When analyzing the results of an experiment, it can be easy to get lost in a build scan and not be sure whether it was the first or second build of the experiment. Often, the best way to check is by assuming from the performance of the build itself or navigating back to the summary view. It would be more concrete to capture this metadata as a tag or custom value so that it would be clear.
The text was updated successfully, but these errors were encountered: