Gitlab not showing build status for bamboo branches
When integrating Bamboo with Gitlab, if branch build plans are enabled, gitlab will always show "CI build pending". I followed all the steps required for the integration. Thanks.
Activity
We are noticing the same exact issue with CE 7.9.1 6f6c5f18.
Initially I stumbled over a different issue: The Bamboo trigger did not work at all at first.
After contacting the original author via his merge request i fixed this issue (see my merge request here). But now I face the same issue here.
I already contacted the Atlassian support, which told me that the REST function used to lookup the build status only works for the master plan, not for any branch plan:
Upon further checking, the
/rest/api/latest/resultendpoint only display latest results from the main plans and not branch plans.Looking at the source of the Bamboo Integration makes it quite clear, that this will not work at all in the current form.
@frederickplante proposed to iterate over all branch plan names: I'm not sure if this is a good idea. Depending on your project a Bamboo plan can easily have 30 or more branch plans which would require up to 31 HTTP request cycle to determine the status. Given that bamboo tends to be utterly slow some times I'm not sure if this is a really good & viable option.
@bentolor I totally agree that looping through each branch is not the right way to deal with this issue. The thing is that with the set of REST endpoints that Bamboo has (for now), I was not able to find another solution. If you find another way to make it work, feel free to share it with us!
So - it turns out that my experience with the Atlassian customer support this time was as devastating unhelpful and a total waste of time, as it always used to be. It's really time for us to move on to TeamCity...
I opened a new ticket at https://jira.atlassian.com/browse/BAM-16121. You could vote there. But honestly: It will make no difference at all. My painfully long watchlist of unresolved tickets affecting us never, ever saw a single "Fixed" status. Typically it will rot there for a little bit of time (let's say... 7-10 years) and then Atlassian will set it to WONTFIX irrespective of any number of votes, watchers, level of business impact or amount of complaining comments.
So I must agree with Frederick: If we want this crap to work with Gitlab, currently the only way is to manually loop and query all plans associated with the build plan key. This won't work either very satisfyingly, because depending on the count of branch plans and the current mood of Bamboo, this will regularly exceed Gitlab's patience.
The basic instructions for setting up Bamboo CI still includes setting up revision labeling, right? If so you can locate builds for a given label (in this case the revision ID) with this REST URI:
http://bamboo-host/rest/api/latest/result?label={revision-id}This will find the build regardless of what build project it lives in and regardless of whether it's in a branch build or not.
@eric2 Are you still on Bamboo 5.6.x or earlier? The REST URI you are proposing is exactly the way, how it is currently implemented. This URL does no longer work for Bamboo 5.7.x for any branch results. This is confirmed by my tests as well as the customer support feedback I quoted above:
[...] the /rest/api/latest/result endpoint only display latest results from the main plans and not branch plans.
I've debugged this a bit more. I think the simple answer is that the build_info link just needs the
build_keyadded to the endpoint. Instead of/rest/api/latest/result?label=#{sha1}we need/rest/api/latest/result/#{build_key}?label=#{sha1}. This seems to give me the build results I expect.I'll work up a PR.
@dblessing This does not work for me: Given my master build plan key is
PME-CI, the endpoint will return an empty result unless I change the build key to the exact branch key for the particular branch/commit i.e.PME-CI59.@dblessing This also does not work for me. I've tried to use the build key, but the results never include branch plan results.
Wow, the Bamboo API is...fun. I may have found an endpoint that will work -
/rest/api/latest/result/#{build_key}/branch/#{branch_name}?label=#{sha1}. I found this at https://docs.atlassian.com/bamboo/REST/5.9.2/Doing more testing now.
mentioned in merge request !975 (closed)
@frederickplante @bentolor and others - Can you please test the small fix in !975 (closed) ? I tested locally with Bamboo version 5.9.1 build 5914 and build status works as expected.
The good news is that I've also gained some ideas on how to improve the triggering of builds. I'll work on that soon.
Thank you @dblessing, for your effort! The modified URL seems to mark indeed a breakthrough: It does return build results for the given Commit Hash even for branch plan results.
But: The URL only works from the Browser if I'm logged in as a user. If I add a trailing
?os_authType=basicparameter and my credentials via HTTP Basic, it works for all cases as expected.Test environment: Bamboo 5.7.2 with Crowd Authentification.
@dblessing This seems to work just fine in 5.9 (with the basic auth).
There is a more direct route not needing this setup :
/rest/api/latest/result/byChangeset/#{sha1}. I've got a MR that uses it. Works for me(edit) MR is !2562 (closed)
Edited by username-removed-34625mentioned in merge request !2562 (closed)
@marache I think your route won't work properly for automatic created feature branches by Bamboo either according to the feedback I got from Atlassian:
Upon further checking, the
/rest/api/latest/resultendpoint only display latest results from the main plans and not branch plans.Please see the other posts in this discussion
@marache This would be really nice. Which Bamboo version are you using?
@bentolor We have 5.9.3 currently, 5.10.0 just got out but haven't had a chance to update yet
Edited by username-removed-34625I just found out that original MR !975 (closed) did the same as mine. However I believe mine can be merged
@marache This is strange: I have 5.9.4 and this is definitely not working for me. A valid Git-SHA built on Bamboo in an automatic created branch plan reports no valid build result:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <results expand="results"> <results expand="result" start-index="0" max-result="0" size="0"/> <link href="https://[bamboo-server]/bamboo/rest/api/latest/result" rel="self"/> </results>In contrast to this the same URL with a SHA1 already built on the main plan does work and returns:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <results expand="results"> <results expand="result" start-index="0" max-result="1" size="1"> <result key="XX-DASH-119" state="Successful" lifeCycleState="Finished" number="119" id="180586551"> <link href="https://[bamboo-server]/bamboo/rest/api/latest/result/XX-DASH-119" rel="self"/> <plan key="XX-DASH" name="Dashboard" shortName="Dashboard" shortKey="DASH" type="chain" enabled="true"> <planKey> <key>XX-DASH</key> </planKey> <link href="https://[bamboo-server]/bamboo/rest/api/latest/plan/XX-DASH" rel="self"/> </plan> <buildResultKey>XX-DASH-119</buildResultKey> <planResultKey> <key>XX-DASH-119</key> <entityKey> <key>XX-DASH</key> </entityKey> <resultNumber>119</resultNumber> </planResultKey> <buildState>Successful</buildState> <buildNumber>119</buildNumber> </result> </results> <link href="https://[bamboo-server]/bamboo/rest/api/latest/result" rel="self"/> </results>Edited by username-removed-182749@bentolor Here is my output sop-bamboo is an internal server so leaving it unscrambled
curl http://sop-bamboo/rest/api/latest/result/byChangeset/82115aa84a484fc206055e13d3e3ae3dbccf3b52<?xml version="1.0" encoding="UTF-8"?> <results expand="results"> <results expand="result" start-index="0" max-result="1" size="1"> <result key="EVEDEV-EPA1-5" state="Successful" lifeCycleState="Finished" number="5" id="96567928"> <link href="http://sop-bamboo/rest/api/latest/result/EVEDEV-EPA1-5" rel="self" /> <plan key="EVEDEV-EPA1" name="eveApps-develop - eveBIM-EPA - feature-4080-TypesList" shortName="feature-4080-TypesList" shortKey="EPA1" type="chain_branch" enabled="true"> <master key="EVEDEV-EPA" name="eveApps-develop - eveBIM-EPA" shortName="eveBIM-EPA" shortKey="EPA" type="chain" enabled="true"> <planKey> <key>EVEDEV-EPA</key> </planKey> <link href="http://sop-bamboo/rest/api/latest/plan/EVEDEV-EPA" rel="self" /> </master> <planKey> <key>EVEDEV-EPA1</key> </planKey> <link href="http://sop-bamboo/rest/api/latest/plan/EVEDEV-EPA1" rel="self" /> </plan> <master key="EVEDEV-EPA" name="eveApps-develop - eveBIM-EPA" shortName="eveBIM-EPA" shortKey="EPA" type="chain" enabled="true"> <planKey> <key>EVEDEV-EPA</key> </planKey> <link href="http://sop-bamboo/rest/api/latest/plan/EVEDEV-EPA" rel="self" /> </master> <buildResultKey>EVEDEV-EPA1-5</buildResultKey> <planResultKey> <key>EVEDEV-EPA1-5</key> <entityKey> <key>EVEDEV-EPA1</key> </entityKey> <resultNumber>5</resultNumber> </planResultKey> <buildState>Successful</buildState> <buildNumber>5</buildNumber> </result> </results> <link href="http://sop-bamboo/rest/api/latest/result" rel="self" /> </results>@marache Your results contains a SHA which is present in a branch plan and the main plan. This works for me as well.
Please test it with a SHA1 which is only present in a feature branch like my upper response.
We discussed with @bentolor on my MR !2562 (closed) :
But it fails if a SHA1 is only present in a branch plan which is IMHO the typical use case for feature branches.
My SHA1 is only present on my feature branch the main plan is on the develop branch. Here is my shell queries on the repo :
$ git fetch $ git branch -r origin/develop origin/feature/4080-TypesList origin/feature/4081-PropertySetList origin/feature/4088-PropertyValue origin/unstable sop-forge/develop sop-forge/unstable $ git branch -r --contains 82115aa84a484fc206055e13d3e3ae3dbccf3b52 origin/feature/4080-TypesListSo I would conclude that the solution that both MR ( !975 (closed) and !2562 (closed) ) give a better solution than the existing one, the later MR being more recent would merge quietly...
How can we get this to someone attention from gitlab ?
@marache Thanks for your work, I will take a look at !2562 (closed), and maybe @dblessing would be also able to look there.
I opened another support request at Atlassian in the rather irrational hope they can help to clarify, why the REST endpoint
/rest/api/latest/resultis working in branch plans for @marache but not in our installation.@grzesiek, @marache, et al. See https://gitlab.com/gitlab-org/gitlab-ce/issues/1355#note_1619585 for a possible alternate endpoint that should work.
I will put this on my list to look at, but it could be a bit. I'll try for 8.5.
Milestone changed to 8.5
Reassigned to @dblessing
It seems I've have an answer for @bentolor I've just noticed that Changesets are not associated to the first build of an automatically created branch. Further builds (triggered by commits) will get associated to changesets and be queryable by the API.
I've filled a bug report to Atlasssian : https://jira.atlassian.com/browse/BAM-17147
Edited by username-removed-34625I can confirm @marache assumption backed by the feedback from the Atlassian Support:
Hi Benjamin,
Thank you for the information. From the attached screenshots I see that this is the first build for this branch plan. This is the behavior for the first build to avoid the case displaying a large number of commits when you build for the first time from a repository with a large history.
The commit id that you see in the screenshot you sent that starts with 9c8ab0 is the commit id that is used for the first build, but this commit id will not be added to the Commits tab.
The following builds that bamboo will make for this branch will contain all the commits that were made between the previous and current build. When you use the REST API to request the results byChangeset you will get results if the changeset is listed in the Commits tab, otherwise the result will be empty.
Cheers, _____
To summarize
- Using labels would allow to link to the Bamboo result even on the first push. But there is no shortcut API to retrieve the result
- Using the SHA1 endpoint will work, but never for the first push/creation of a branch
Nevertheless the change that it will work at least for some cases is better than for no cases.
mentioned in merge request !4367 (closed)
mentioned in merge request !4408 (merged)
mentioned in commit 0068ba8d
Mentioned in issue #17556 (moved)
moved to gitlab#3729
Hey!
GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current
gitlab-cerepository will become a read-only mirror, without any proprietary code. All development is moved to the currentgitlab-eerepository, which we will rename to justgitlabin the coming weeks. As part of this migration, issues will be moved to the currentgitlab-eeproject.If you have any questions about all of this, please ask them in our dedicated FAQ issue.
https://gitlab.com/gitlab-org/gitlab-ee/issues/13855You can also find more information here:
https://gitlab.com/gitlab-org/gitlab-ee/issues/13304- https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/
Frequently Asked Questions
For an up to date list of questions and answers, please take a look at
https://gitlab.com/gitlab-org/gitlab-ee/issues/13855What will we do with the repository names?
https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.
Why rename gitlab-ce to gitlab-foss?
Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear
I created a merge requests for CE, and this got closed. What do I need to do?
You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.
How does the licensing work in this new setup?
Everything in the
ee/directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in theee/directory, the process of contributing changes is the same as when using the gitlab-ce repository.Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?
No. Merge requests submitted to this project will be closed automatically.
Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?
Yes.
How will this affect users of GitLab CE using Omnibus?
No changes will be necessary, as the packages built remain the same.
How will this affect users of GitLab CE that build from source?
Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.
Where can I see a timeline of the remaining steps?
https://gitlab.com/gitlab-org/gitlab-ee/issues/13304Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?
Yes, these changes will be synced to gitlab-foss automatically, several times per day.
mentioned in merge request !14785
