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

Enhanced TeamCity Logging #2111

Merged
merged 12 commits into from Sep 27, 2018

Conversation

Projects
None yet
3 participants
@BlythMeister
Copy link
Contributor

BlythMeister commented Sep 27, 2018

Description

Superseeds: #2109
Fixes #2108

Update TeamCity listener to match the documentation for service messages
Add functionality in the targets to report build state through trace

otto-gebb and others added some commits Sep 26, 2018

@otto-gebb

This comment has been minimized.

Copy link
Contributor

otto-gebb commented on de7ffff Sep 27, 2018

Can also remove parameters while you are here.

@otto-gebb

This comment has been minimized.

Copy link
Contributor

otto-gebb commented on src/app/Fake.BuildServer.TeamCity/TeamCity.fs in 0ba928c Sep 27, 2018

Sends an error message.

BlythMeister added some commits Sep 27, 2018

@@ -394,10 +403,15 @@ module TeamCity =
match description with
| Some d -> TeamCityWriter.sendOpenBlock tag.Name (sprintf "%s: %s" tag.Type d)
| _ -> TeamCityWriter.sendOpenBlock tag.Name tag.Type
| TraceData.CloseTag (tag, _, status) when status = TagStatus.Failed ->

This comment has been minimized.

@matthid

matthid Sep 27, 2018

Collaborator

| TraceData.CloseTag (tag, _, TagStatus.Failed)?

This comment has been minimized.

@BlythMeister

BlythMeister Sep 27, 2018

Author Contributor

Wait...that's a thing...

This comment has been minimized.

@matthid

matthid Sep 27, 2018

Collaborator

Called "pattern matching" ;)

BlythMeister added some commits Sep 27, 2018

@BlythMeister

This comment has been minimized.

Copy link
Contributor Author

BlythMeister commented Sep 27, 2018

@matthid this all good now?

@@ -39,11 +39,13 @@ module TeamCityImportExtensions =
/// The general documentation on how to use CI server integration can be found [here](/buildserver.html).
/// This module does not provide any special APIs please use FAKE APIs and they should integrate into this CI server.
/// If some integration is not working as expected or you have features you would like to use directly please open an issue.
///
/// For more information on TeamCity interaction from builc scripts [see here](https://confluence.jetbrains.com/display/TCD18/Build+Script+Interaction+with+TeamCity)

This comment has been minimized.

@matthid

matthid Sep 27, 2018

Collaborator

I'd assume more important would be how to set the "fail on traceError flag" and how fake in particular interacts with TeamCity. I don't think just the link to teamcity docs helps fake users here.

I'd love to see another PR to improve the docs but I'm not blocking this one

@matthid matthid merged commit e4da873 into fsharp:release/next Sep 27, 2018

2 of 3 checks passed

continuous-integration/travis-ci/pr The Travis CI build failed
Details
ci/circleci Your tests passed on CircleCI!
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details

@matthid matthid referenced this pull request Sep 27, 2018

Merged

Release 5.8.4 #2116

else
alignedError "Status:" "Failure" null
Trace.setBuildState TagStatus.Failed

This comment has been minimized.

@matthid

matthid Oct 5, 2018

Collaborator

@BlythMeister Is there any particular reason why we need that? I'm asking because I just realized (after trying to figure out for hours which commit is to blame) that this makes the VSTS build red. This is because we have some testing going on with negative/failing cases which will call this API and make the build red.

This comment has been minimized.

@BlythMeister

BlythMeister Oct 5, 2018

Author Contributor

The reason is so that when running on a CI (like teamcity) when the build fails the state is set to failure.
It's to try and prevent the build failure ending with "Process returned exit code 1"

This comment has been minimized.

@matthid

matthid Oct 5, 2018

Collaborator

But shouldn't that Process returned exit code 1 already be solved by using the error apis?

This comment has been minimized.

@BlythMeister

BlythMeister Oct 5, 2018

Author Contributor

possibly...happy to revert this bit of the change and try

This comment has been minimized.

@BlythMeister

BlythMeister Oct 5, 2018

Author Contributor

It does mean though that any listener with "TraceData.BuildState" is a bit pointless as nothing ever traces with that...

This comment has been minimized.

@BlythMeister

BlythMeister Oct 5, 2018

Author Contributor

How about we make it so there is a new run or update existing runs to return the TargetContext from runInternal
That way, as a user you can make the decision to react to the overall run result...

This comment has been minimized.

@BlythMeister

BlythMeister Oct 5, 2018

Author Contributor

(facepalm)....a bit like runAndGetContext

I'll shut up :)

This comment has been minimized.

@BlythMeister

BlythMeister Oct 5, 2018

Author Contributor
match context.PreviousTargets.Length, context.HasError with
| 0, _ -> Trace.setBuildState TagStatus.Warning
| _, true -> Trace.setBuildState TagStatus.Failed
| _, _ -> Trace.setBuildState TagStatus.Success

in my script after calling runAndGetContext means it does what i want :)

This comment has been minimized.

@matthid

matthid Oct 5, 2018

Collaborator

Yes I should have been a bit more conservative with these changes... Found another edge case where the build went red in teamcity (good that we have a teamcity build now) so I need a bit more time to release this properly.

Regarding your suggestion. Yes indeed we could make that an opt-in api:

let context = Target.tryRunOrDefaultAndGetContext "Default"
Target.reportBuildStateFromContext context

(Or something along those lines)

Can you open a PR or an issue for this (so it is not forgotten in this PR)

This comment has been minimized.

@BlythMeister

BlythMeister Oct 5, 2018

Author Contributor

I'll take a look next week and ensure that all run methods also have a WithContext
and add a function to report status based on context which you could (and I will) pipe the run into.
Watch this space 😂

matthid added a commit that referenced this pull request Oct 5, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
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.