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

[Question] Build Status for Pull Requests #22

Closed
gep13 opened this Issue Aug 25, 2014 · 15 comments

Comments

Projects
None yet
4 participants
@gep13

gep13 commented Aug 25, 2014

I have my TeamCity Server setup to trigger a build when Pull Requests are created in Stash, using:

+:refs/pull-requests/*/merge

Are you expecting that the Build Status from the resulting build should be reported back and displayed "somewhere" in Stash?

Unless I am looking in the wrong place, I don't seem to see this status anywhere.

Thanks!

@mendhak

This comment has been minimized.

Show comment
Hide comment
@mendhak

mendhak Aug 25, 2014

Owner

Greetings gep, longtimenosee...

I don't believe you'll see it reported back in Stash. See this thread:

#2

Owner

mendhak commented Aug 25, 2014

Greetings gep, longtimenosee...

I don't believe you'll see it reported back in Stash. See this thread:

#2

@gep13

This comment has been minimized.

Show comment
Hide comment
@gep13

gep13 Aug 25, 2014

I was wondering if you would remember me 👍

Ah, no worries, I just wanted to check, in case I was looking in the wrong place.

The process that we have just adopted, relies heavily on first creating pull requests in stash, going through an informal code review through the Stash interface, and then pulling into the main branch, so it would have been ideal to see the build status reported directly in the pull request.

P.S. Where is the frog avatar :-P

gep13 commented Aug 25, 2014

I was wondering if you would remember me 👍

Ah, no worries, I just wanted to check, in case I was looking in the wrong place.

The process that we have just adopted, relies heavily on first creating pull requests in stash, going through an informal code review through the Stash interface, and then pulling into the main branch, so it would have been ideal to see the build status reported directly in the pull request.

P.S. Where is the frog avatar :-P

@mendhak

This comment has been minimized.

Show comment
Hide comment
@mendhak

mendhak Aug 25, 2014

Owner

You should still see the build status reported as part of the pull request. See where it says "1 Build", this is from our own Stash.

image

image

We follow a similar pattern, where every branch must build and pass tests before being merged. The difference is that you are using +:refs/pull-requests/*/merge, but we simply go +:refs/heads/*. If you do the +:refs/heads/* way, you should then start seeing build statuses.

In other words, don't try to build just the pull request, build everything, regardless of branch.

Owner

mendhak commented Aug 25, 2014

You should still see the build status reported as part of the pull request. See where it says "1 Build", this is from our own Stash.

image

image

We follow a similar pattern, where every branch must build and pass tests before being merged. The difference is that you are using +:refs/pull-requests/*/merge, but we simply go +:refs/heads/*. If you do the +:refs/heads/* way, you should then start seeing build statuses.

In other words, don't try to build just the pull request, build everything, regardless of branch.

@gep13

This comment has been minimized.

Show comment
Hide comment
@gep13

gep13 Aug 25, 2014

Hmm, I am not seeing that, I only have this:

image

I was recently messing with the Stash configuration, where I switched to using Jira User Directory, rather than a local account.

I had a quick look around to see if there was a log file associated with the build feature to see if the request to Stash wasn't getting through, but I couldn't find any obvious log file. Don't suppose you know if there is one I could check do you? Cheers!

gep13 commented Aug 25, 2014

Hmm, I am not seeing that, I only have this:

image

I was recently messing with the Stash configuration, where I switched to using Jira User Directory, rather than a local account.

I had a quick look around to see if there was a log file associated with the build feature to see if the request to Stash wasn't getting through, but I couldn't find any obvious log file. Don't suppose you know if there is one I could check do you? Cheers!

@mendhak

This comment has been minimized.

Show comment
Hide comment
@mendhak

mendhak Aug 25, 2014

Owner

Did you change TC to build all commits? Change the VCS watch to +:refs/heads/*.

Everything will be logged to catalina.out, under the TeamCity folder, you should be able to find the logs folder. In catalina.out, you will very likely notice an internal SHA commit number which doesn't correspond to anything in Stash. Instead you want the latest commit in the pull request to be built and Stash reports on that.

Owner

mendhak commented Aug 25, 2014

Did you change TC to build all commits? Change the VCS watch to +:refs/heads/*.

Everything will be logged to catalina.out, under the TeamCity folder, you should be able to find the logs folder. In catalina.out, you will very likely notice an internal SHA commit number which doesn't correspond to anything in Stash. Instead you want the latest commit in the pull request to be built and Stash reports on that.

@gep13

This comment has been minimized.

Show comment
Hide comment
@gep13

gep13 Aug 26, 2014

Did you change TC to build all commits?

Is this a pre-requisite?

I actually turned this off the other day, as a change in our flow made it better (at least for us) to specifically not do this. We are attempting to follow GitFlow (first time for us). As a result, we have a number of small feature branches that are worked on in isolation, without any CI. Once they are at a point that additional input or review is required, a pull request is raised from the feature branch onto develop. Rather than run multiple builds for the PR (which could involve a number of commits and also a merge commit by Stash), we have it set up to trigger within the "Quiet Period" so that all the commits are built as one build in TeamCity. Once the PR has been reviewed, we merge into the develop branch, which then triggering a snapshot build to push the artifacts onto the development server using Octopus Deploy. All of this means that I don't have the option to build on every commit. Does any of that make sense? Or do you think I am doing something outwith the norm?

Although I can see multiple catalina.* files, I can't see any specifically named catalina.out and I couldn't find any specific reference to the build feature running against stash.

gep13 commented Aug 26, 2014

Did you change TC to build all commits?

Is this a pre-requisite?

I actually turned this off the other day, as a change in our flow made it better (at least for us) to specifically not do this. We are attempting to follow GitFlow (first time for us). As a result, we have a number of small feature branches that are worked on in isolation, without any CI. Once they are at a point that additional input or review is required, a pull request is raised from the feature branch onto develop. Rather than run multiple builds for the PR (which could involve a number of commits and also a merge commit by Stash), we have it set up to trigger within the "Quiet Period" so that all the commits are built as one build in TeamCity. Once the PR has been reviewed, we merge into the develop branch, which then triggering a snapshot build to push the artifacts onto the development server using Octopus Deploy. All of this means that I don't have the option to build on every commit. Does any of that make sense? Or do you think I am doing something outwith the norm?

Although I can see multiple catalina.* files, I can't see any specifically named catalina.out and I couldn't find any specific reference to the build feature running against stash.

@mendhak

This comment has been minimized.

Show comment
Hide comment
@mendhak

mendhak Aug 26, 2014

Owner

Thing is, until the merge commit's status is publicly recognized by Stash, you're not going to get any build status appear. However, that merge commit is an internal one as the Stash devs have said, so you won't get anything.

We're also using git workflow, so there are two ways to go about this.

You can have everyone working in feature branches, but when they submit a pull request, they need to go into TeamCity and manually invoke a build for their specific commit (and each subsequent update). This won't work well, IMO.

The other option is to build every commit, but only deploy the develop branch to your environments. So in my case, we may get dozens of builds in a day, but we only ever deploy the develop and release branch. So the key may be for you to filter specific branches to be deployed, but build everything. Unless there's some missing detail, it doesn't look like you're doing anything to require not building. PRs are the most important time after all, that's when a dev tries to push commits quickly in their "oops, I forgot that" moment and tend to be careless.

Yes, it's normal practice to trigger a build on every commit. Your current setup only 'displays' a build status after it will get merged into develop, by then it's too late.

Regarding the log files, I'd say have a look at which one is last updated and look through there for messages. If there's no catalina.out, it may be in teamcity-server.log.

Owner

mendhak commented Aug 26, 2014

Thing is, until the merge commit's status is publicly recognized by Stash, you're not going to get any build status appear. However, that merge commit is an internal one as the Stash devs have said, so you won't get anything.

We're also using git workflow, so there are two ways to go about this.

You can have everyone working in feature branches, but when they submit a pull request, they need to go into TeamCity and manually invoke a build for their specific commit (and each subsequent update). This won't work well, IMO.

The other option is to build every commit, but only deploy the develop branch to your environments. So in my case, we may get dozens of builds in a day, but we only ever deploy the develop and release branch. So the key may be for you to filter specific branches to be deployed, but build everything. Unless there's some missing detail, it doesn't look like you're doing anything to require not building. PRs are the most important time after all, that's when a dev tries to push commits quickly in their "oops, I forgot that" moment and tend to be careless.

Yes, it's normal practice to trigger a build on every commit. Your current setup only 'displays' a build status after it will get merged into develop, by then it's too late.

Regarding the log files, I'd say have a look at which one is last updated and look through there for messages. If there's no catalina.out, it may be in teamcity-server.log.

@gep13

This comment has been minimized.

Show comment
Hide comment
@gep13

gep13 Aug 26, 2014

Hmmm.... :-)

Ok, I think I follow what you are saying, and this will only be a slight modification to the current structure that I have. The deployment step is already a separate build configuration, that only looks at the develop/master branches. The CI build looks at everything else, but expressly doesn't trigger on check in's to develop/master, instead, relying on the snapshot dependency to trigger the "child" build based on a change to the "parent" one.

Sorry, this is getting completely off topic for your Stash Plugin :-)

gep13 commented Aug 26, 2014

Hmmm.... :-)

Ok, I think I follow what you are saying, and this will only be a slight modification to the current structure that I have. The deployment step is already a separate build configuration, that only looks at the develop/master branches. The CI build looks at everything else, but expressly doesn't trigger on check in's to develop/master, instead, relying on the snapshot dependency to trigger the "child" build based on a change to the "parent" one.

Sorry, this is getting completely off topic for your Stash Plugin :-)

@gep13

This comment has been minimized.

Show comment
Hide comment
@gep13

gep13 Aug 26, 2014

@mendhak Just wanted to let you know that I have it all working :-)

I have build statuses for each commit:

image

And also for Pull Requests:

image

And I also have the deployment from develop working correctly through Octopus Deploy as part of my build chain:

image

Thanks for the pointer in the right direction!

gep13 commented Aug 26, 2014

@mendhak Just wanted to let you know that I have it all working :-)

I have build statuses for each commit:

image

And also for Pull Requests:

image

And I also have the deployment from develop working correctly through Octopus Deploy as part of my build chain:

image

Thanks for the pointer in the right direction!

@gep13 gep13 closed this Aug 26, 2014

@gep13

This comment has been minimized.

Show comment
Hide comment
@gep13

gep13 Aug 27, 2014

@mendhak quick follow up question....

This has nothing to do with your TeamCity-Stash plugin, but was hoping you might know :-)

We just created a Pull Request, and the associated TeamCity build kicked off, as expected, but it queued up 43 builds. One for each commit. However, in this Pull Request, there were only 8 additional commits on top of what was already created in Stash. Do you know why TeamCity is essentially going back in time and running builds for commits that have already been built? Thanks!

gep13 commented Aug 27, 2014

@mendhak quick follow up question....

This has nothing to do with your TeamCity-Stash plugin, but was hoping you might know :-)

We just created a Pull Request, and the associated TeamCity build kicked off, as expected, but it queued up 43 builds. One for each commit. However, in this Pull Request, there were only 8 additional commits on top of what was already created in Stash. Do you know why TeamCity is essentially going back in time and running builds for commits that have already been built? Thanks!

@laurentkempe

This comment has been minimized.

Show comment
Hide comment
@laurentkempe

laurentkempe Aug 27, 2014

@gep13 Do wou have TeamCity Per-checkin Triggering set in VCS Trigger in your build Triggers?

laurentkempe commented Aug 27, 2014

@gep13 Do wou have TeamCity Per-checkin Triggering set in VCS Trigger in your build Triggers?

@mendhak

This comment has been minimized.

Show comment
Hide comment
@mendhak

mendhak Aug 27, 2014

Owner

Edit: What @laurentkempe said

Owner

mendhak commented Aug 27, 2014

Edit: What @laurentkempe said

@gep13

This comment has been minimized.

Show comment
Hide comment
@gep13

gep13 Aug 27, 2014

@laurentkempe @mendhak yes:

image

And I understand that it should trigger a build for each commit. However, the most recent pull request triggered 43 builds, but the pull request that was created only had 7 commits. Where did the other commits come from, and why did TeamCity trigger builds for them?

Cheers!

gep13 commented Aug 27, 2014

@laurentkempe @mendhak yes:

image

And I understand that it should trigger a build for each commit. However, the most recent pull request triggered 43 builds, but the pull request that was created only had 7 commits. Where did the other commits come from, and why did TeamCity trigger builds for them?

Cheers!

@gep13

This comment has been minimized.

Show comment
Hide comment
@gep13

gep13 Sep 2, 2014

In case anyone else is running into a similar issue as above, with the help of @maartenba we were able to track down the issue, which is described here:

http://devnet.jetbrains.com/message/5522613

Ultimately, the workaround is described in this YouTrack issue:

https://youtrack.jetbrains.com/issue/TW-29820

Thanks

gep13 commented Sep 2, 2014

In case anyone else is running into a similar issue as above, with the help of @maartenba we were able to track down the issue, which is described here:

http://devnet.jetbrains.com/message/5522613

Ultimately, the workaround is described in this YouTrack issue:

https://youtrack.jetbrains.com/issue/TW-29820

Thanks

@crick231

This comment has been minimized.

Show comment
Hide comment
@crick231

crick231 Aug 27, 2016

+:refs/heads/* -> I tried this but it gives error. Cant I build same pull request multiple times with this plugin? Only for the first time when build automatically gets triggered after pull request, after that even if I trigger the build manually, I dont see build notification count being incremented on stash. It shows only first build result. Am I missing anything?

crick231 commented Aug 27, 2016

+:refs/heads/* -> I tried this but it gives error. Cant I build same pull request multiple times with this plugin? Only for the first time when build automatically gets triggered after pull request, after that even if I trigger the build manually, I dont see build notification count being incremented on stash. It shows only first build result. Am I missing anything?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment