Skip to content
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

[msbuild] Improve altool task by logging execution errors #6815

Merged
merged 2 commits into from
Aug 23, 2019

Conversation

emaf
Copy link
Contributor

@emaf emaf commented Aug 20, 2019

The altool task was just logging the XML output produced by the tool execution but was not logging any build error neither failing in that case.

The altool task was just logging the XML output produced by the tool execution but was not logging any build error neither failing in that case.
Copy link
Contributor

@spouliot spouliot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor feedback

}
}
} catch (Exception ex) {
Log.LogWarning ("Failed to parse altool output: {0}", ex.Message);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should you include output in the exception log ?
That way you can get a clue of what went wrong

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also $"Failed to parse altool output: {ex.Message}" looks nicer :)

void LogErrorsFromOutput (string output)
{
try {
if (string.IsNullOrEmpty(output))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor: space before (

foreach (var error in errors) {
var dict = error as PDictionary;
if (dict?.TryGetValue ("message", out message) == true) {
Log.LogError (ToolName, null, null, null, 0, 0, 0, 0, "{0}", message.Value);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure if the API (or some overloads) allows it but "{0}" seems to require a call to String.Format, can't you just provide message.Value ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@spouliot What if message.Value contains something that can be a format string? Say "{0}" for instance, then things might fail (depending on LogError's implementation).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, bring us back to not sure if the API :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I don't really like it (using "{0}") but it seems to be safer, and that's how most of the XI tasks log errors that come from tool outputs or text we don't control.

@spouliot spouliot added this to the xcode11 milestone Aug 21, 2019
@monojenkins
Copy link
Collaborator

Build success
Build succeeded
API Diff (from stable)
API Diff (from PR only) (no change)
Generator Diff (no change)
Test run succeeded

}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unnecessary space change

foreach (var error in errors) {
var dict = error as PDictionary;
if (dict?.TryGetValue ("message", out message) == true) {
Log.LogError (ToolName, null, null, null, 0, 0, 0, 0, "{0}", message.Value);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@spouliot What if message.Value contains something that can be a format string? Say "{0}" for instance, then things might fail (depending on LogError's implementation).

@monojenkins
Copy link
Collaborator

Build failure
Build failed or was aborted

🔥 Build failed 🔥

@rolfbjarne
Copy link
Member

build

1 similar comment
@rolfbjarne
Copy link
Member

build

@monojenkins
Copy link
Collaborator

Build success
Build succeeded
API Diff (from stable)
API Diff (from PR only) (no change)
Generator Diff (no change)
Test run succeeded

@emaf
Copy link
Contributor Author

emaf commented Aug 23, 2019

@rolfbjarne could you review the latest changes? Is there anything else needed to get this PR merged?

@rolfbjarne rolfbjarne merged commit 616d654 into xamarin:xcode11 Aug 23, 2019
@emaf emaf deleted the xcode11-altool branch August 23, 2019 16:23
@rolfbjarne rolfbjarne added the not-notes-worthy Ignore for release notes label Sep 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
not-notes-worthy Ignore for release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants