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
Add status reason messaging #833
Changes from 30 commits
94d364b
e822fbc
72ca723
633ea76
74d7f0f
e67b814
e561d66
45f9389
5df29c9
c4c8447
96c7e25
c73bdc1
da051c4
a5ba8bd
069dfff
4d53b36
cff54e3
036a5d0
eca7af3
3254390
cd3ef07
a0208c2
05c45fb
eefee40
d3e84c9
5900a0a
7f4d85f
735d934
b58b743
4b88264
8796da7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1630,8 +1630,11 @@ route_map: | |
// Then | ||
require.NoError(t, err) | ||
for _, expectedEvent := range test.expectedTriggeredEvents { | ||
output := buf.String() | ||
assert.True(t, strings.Contains(output, expectedEvent), output) | ||
condition := func() bool { | ||
output := buf.String() | ||
return strings.Contains(output, expectedEvent) | ||
} | ||
assert.Eventuallyf(t, condition, 5*time.Second, 150*time.Millisecond, "", "") | ||
Comment on lines
+1633
to
+1637
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why is this new assert needed? From what I can see in the test that we save the loggers output into a buffer and run a test workflow. By the time we reach this assertion the workflow run should be over and we should have the output in the buffer. I think we do not do any concurrent operation in the cli (workflow related). I was curious and restored the previous assertion and did 5 test runs locally and it was always passing. Is this flaky on the CI? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The test case ( |
||
} | ||
} | ||
} | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -218,14 +218,14 @@ func CreateBitriseConfigFromCLIParams(bitriseConfigBase64Data, bitriseConfigPath | |
bitriseConfig = config | ||
} | ||
|
||
isConfigVersionOK, err := versions.IsVersionGreaterOrEqual(models.Version, bitriseConfig.FormatVersion) | ||
isConfigVersionOK, err := versions.IsVersionGreaterOrEqual(models.FormatVersion, bitriseConfig.FormatVersion) | ||
if err != nil { | ||
log.Warn("bitrise CLI model version: ", models.Version) | ||
log.Warn("bitrise CLI model version: ", models.FormatVersion) | ||
log.Warn("bitrise.yml Format Version: ", bitriseConfig.FormatVersion) | ||
return models.BitriseDataModel{}, warnings, fmt.Errorf("Failed to compare bitrise CLI models's version with the bitrise.yml FormatVersion: %s", err) | ||
} | ||
if !isConfigVersionOK { | ||
log.Warnf("The bitrise.yml has a higher Format Version (%s) than the bitrise CLI model's version (%s).", bitriseConfig.FormatVersion, models.Version) | ||
log.Warnf("The bitrise.yml has a higher Format Version (%s) than the bitrise CLI model's version (%s).", bitriseConfig.FormatVersion, models.FormatVersion) | ||
return models.BitriseDataModel{}, warnings, errors.New("This bitrise.yml was created with and for a newer version of bitrise CLI, please upgrade your bitrise CLI to use this bitrise.yml") | ||
} | ||
|
||
|
@@ -607,6 +607,7 @@ func activateAndRunSteps( | |
// Per step variables | ||
stepStartTime = time.Now() | ||
isLastStep := isLastWorkflow && (idx == len(workflow.Steps)-1) | ||
// TODO: stepInfoPtr.Step is not a real step, only stores presentation properties (printed in the step boxes) | ||
stepInfoPtr := stepmanModels.StepInfoModel{} | ||
stepIdxPtr := idx | ||
|
||
|
@@ -707,6 +708,18 @@ func activateAndRunSteps( | |
stepInfoPtr.Step.SourceCodeURL = pointers.NewStringPtr(*mergedStep.SourceCodeURL) | ||
} | ||
|
||
if mergedStep.RunIf != nil { | ||
stepInfoPtr.Step.RunIf = pointers.NewStringPtr(*mergedStep.RunIf) | ||
} | ||
|
||
if mergedStep.Timeout != nil { | ||
stepInfoPtr.Step.Timeout = pointers.NewIntPtr(*mergedStep.Timeout) | ||
} | ||
|
||
if mergedStep.NoOutputTimeout != nil { | ||
stepInfoPtr.Step.NoOutputTimeout = pointers.NewIntPtr(*mergedStep.NoOutputTimeout) | ||
} | ||
Comment on lines
+711
to
+721
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. These are needed because they were not set on the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes, if you search for
Then the added fields are used for creating the status reason: https://github.com/bitrise-io/bitrise/blob/CI-318/cli/build_run_result_collector.go#L184 |
||
|
||
// At this point we have a filled up step info model and also have a step model which is contains the merged step | ||
// data from the bitrise.yml and the steps step.yml. | ||
// If the step title contains the step id or the step library as a prefix then we will take the original steps | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -8,6 +8,7 @@ import ( | |
"github.com/bitrise-io/bitrise/log/corelog" | ||
"github.com/bitrise-io/bitrise/models" | ||
"github.com/bitrise-io/bitrise/utils" | ||
"github.com/bitrise-io/go-utils/colorstring" | ||
"github.com/bitrise-io/go-utils/stringutil" | ||
) | ||
|
||
|
@@ -63,10 +64,10 @@ func getHeaderLine(content string) string { | |
} | ||
|
||
func widthConstrainedStringWithBorder(content string, width int) string { | ||
return fmt.Sprintf("| %s |", widthConstrainedString(content, width)) | ||
return fmt.Sprintf("| %s |", WidthConstrainedString(content, width)) | ||
} | ||
|
||
func widthConstrainedString(content string, width int) string { | ||
func WidthConstrainedString(content string, width int) string { | ||
widthDiff := len(content) - width | ||
|
||
if widthDiff < 0 { | ||
|
@@ -91,9 +92,17 @@ func generateStepFinishedFooterLines(params StepFinishedParams) []string { | |
} | ||
|
||
var lines []string | ||
|
||
for _, stepError := range params.Errors { | ||
lines = append(lines, colorstring.Red(stepError.Message)) | ||
} | ||
if params.StatusReason != "" { | ||
lines = append(lines, colorstring.Blue(params.StatusReason)) | ||
} | ||
Comment on lines
+96
to
+101
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have to admit you tricked me with this clever solution. 😂 I set a step preparation failed error and was debugging who prints the error inside the step box because at first look it did not make sense. The step did not run and still someone printed the error there. And if I ran it with json output then there were only the step started and step finished events and nothing in between. But then I pieced it together and realised that the step footer now prints the errors and status reason as part of the main step body. It is was tricky for me to understand because my mind thought that the step footer always starts with the step timing information. I do not have a better solution but just wanted highlight that this might be a little bit confusing the first time you encounter it. |
||
lines = append(lines, sectionSeparator) | ||
lines = append(lines, mainSeparator) | ||
lines = append(lines, getSummaryFooterRow(params.InternalStatus, params.Title, params.StatusReason, params.RunTime, deprecated)) | ||
status := models.NewStepRunStatus(params.Status) | ||
lines = append(lines, getSummaryFooterRow(status, params.Title, status.Name(), params.RunTime, deprecated)) | ||
lines = append(lines, mainSeparator) | ||
|
||
hasPreviousSection := false | ||
|
@@ -132,15 +141,15 @@ func generateStepFinishedFooterLines(params StepFinishedParams) []string { | |
return lines | ||
} | ||
|
||
func getSummaryFooterRow(status int, title, reason string, duration int64, deprecated bool) string { | ||
func getSummaryFooterRow(status models.StepRunStatus, title, reason string, duration int64, deprecated bool) string { | ||
icon, level := transformStatusToIconAndLevel(status) | ||
footerTitle := getFooterTitle(level, title, reason, deprecated, footerTitleBoxWidth) | ||
executionTime := getFooterExecutionTime(duration) | ||
|
||
return fmt.Sprintf("|%s|%s|%s|", icon, footerTitle, executionTime) | ||
} | ||
|
||
func transformStatusToIconAndLevel(status int) (string, corelog.Level) { | ||
func transformStatusToIconAndLevel(status models.StepRunStatus) (string, corelog.Level) { | ||
var icon string | ||
var level corelog.Level | ||
|
||
|
@@ -202,10 +211,10 @@ func getFooterTitle(level corelog.Level, title, reason string, deprecated bool, | |
|
||
// Deduct the deprecated prefix length and the space between them to only shorten the title | ||
actualWidth = actualWidth - len(deprecatedPrefix) - 1 | ||
widthConstrainedTitle := widthConstrainedString(title, actualWidth) | ||
widthConstrainedTitle := WidthConstrainedString(title, actualWidth) | ||
title = fmt.Sprintf("%s %s", corelog.AddColor(corelog.ErrorLevel, deprecatedPrefix), corelog.AddColor(level, widthConstrainedTitle)) | ||
} else { | ||
title = widthConstrainedString(title, actualWidth) | ||
title = WidthConstrainedString(title, actualWidth) | ||
title = corelog.AddColor(level, title) | ||
} | ||
|
||
|
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.
I prefer this way when every step related error appears inside the step box. Even if technically for these step preparation errors the step was not started. But does this new behaviour needs to be coordinated with the FE team? Because previously this error was appearing as a bitrise cli error before the step start event and now the error only appears in the step finished event.
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.
AFAIK bitrise CLI logs are not shown when structured logging is enabled, this mostly changes how the console log is presented.