I'm new to Jenkins. I'm using Jenkins 2.5. I'm using the TFS plugin (https://wiki.jenkins-ci.org/display/JENKINS/Team+Foundation+Server+Plugin) 4.1.0. Whenever I run a job that gets latest from TFS, TFS first lists every workspace which is a problem because I work for a large company - it lists 5,000 workspaces. This page https://github.com/jenkinsci/tfs-plugin/pull/65/commits seems to indicate that a ShowWorkspaces flag was added, but I can't find it anywhere. Maybe this was never added. Does anyone have a way to get Jenkins to stop listing all TFS workspaces?
It's a known issue for now. And seem to be fixed until version 4.2.0
I'll most likely include a fix for this defect in version 4.2; I'll
update this issue once it's released.
Olivier Dagenais
Moreover, this flag was added successful https://github.com/jenkinsci/tfs-plugin/pull/65/commits/d56346c4b3989a3edaed547ae55ed39233743be8
Related
I'm about to migrate Jenkins from version 2.190.3 to 2.204.6. As I know, I need to update installed plugins manually after updating Jenkins. I've got two questions here.
Does the Jenkins update affect current plug-in? or does it work the same as before updating the plug-in?
How can I find the expected side effects when I proceed with the update? Are there any tips?
Does the Jenkins update affect current plug-in? or does it work the same as before updating the plug-in?
Ans: Jenkins only update jenkin-core, it doesn't update current plugin. However, some plugin may be broken after update Jenkins-core due to incompatibility to new Jenkins-core
How can I find the expected side effects when I proceed with the update? Are there any tips?
Ans: we can not to be sure any expected side effect. So, when you proceed with the update, just go to "Manage Jenkins", it will shows you broken plugins that need to be upgraded to new version.
The recommended approach is to update all your plugins to "latest (compatible)" as possible, then upgrade Jenkins, the upgrade your plugins again.
Read the Upgrade Guide ans Change log. 2.204.6 is still very old. Recommend to 2.263.4 first as 2.277.x will break many plugins as a result of tables to divs migration.
Plugins are/must be upgraded separately from the app. Existing plugins may no longer be compatible, typically for security issues or a core plugins being decoupled. Some plugins may only work with newer core versions.
You should take a copy of your instance & config, update that and validate, then move to your real system.
Is there a way to sort the list of project spaces in Bitbucket? We started using Bitbucket for just a small section of the company now the entire company uses it and we have about 40 project spaces and Bitbucket and the order seems random. The original projects added years back are on the bottom (when we started using Stash 3.x) and all the newer ones (since upgrading to 4.x) are ordered alphabetically on top.
I'm sure I can poke around in the database to solve this but I'm looking for a UI- or API-based solution.
Projects in Bitbucket Server should sort in alphanumeric order. If you're not seeing that, you're experiencing a bug.
I work for Atlassian and I found and reported just such a bug when Bitbucket 5.0 was released. If perchance you're running one of the affected versions, you can resolve it by upgrading to a more recent version.
If you're running an older version than the ones listed in the above bug report, it's still possible you're running into a similar or the same bug - we list "affected versions" based on customer reports, so it's possible the bug existed on an older version but was never reported. On that bug report I provided a python script to easily reproduce the issue on a test instance, so if you can tell me the version of Bitbucket your company is running I can test it to see if it's reproducible.
We're using SonarQube 5.6.6 (LTS) with SonarC# plugin version 6.5.0.3766 and TFS 2017 update 2 (SonarQube plugin v. 3.0.2).
We're repeatedly seeing, that issues that were previously marked as resolved (Won't fix) get reopened. My question is: Why does SonarQube behave in this way?
This issue is also mentioned in a number of different posts(1,2,3) on StackOverflow but with no root cause or resolution. Link 3 also states that this is an issue using SonarQube 6.2.
I'm curious as to whether this is due to a misconfiguration on our part or an integrated part of SonarQube?
Our SonarQube server is running on a Win 2012 R2 server with a MS SQL backend if thats relevant?
Furthermore, we're using TFVC for versioning and get blame through the SCM plugin. If an issues has been marked as resolved (won't fix), I've noticed that it appears to be as opened as a new issue (i.e. no history available).
Example: A colleague marked an issue as resolved (won't fix) in a file which was last modified in TFVC back in november 2015. However, this morning the issue was marked as open and assigned to the developer who originally checked in the code There is no history in SonarQube of the issue having previously been in a resolved state. It appears as if it's a new issue in a new file instead of being a known issue which has already been resolved?
To avoid weird issues related to compiling our C# solution we always clean our workspace completely prior to our build. I don't know if that has something to say? Our builds are also executed on different build machines so I don't know if that will make SonarQube think that we're indeed always analyzing new files?
Could the use of different build machines and/or build definitions for the same SonarQube project result in this behavior?
I've also seen from the logs and reports, that SonarQube appears to analyze the ENTIRE solution and not only the changed files. This makes our analysis very time consuming and not at all suitable in a fast feedback loop. I suspect the long analysis period and the issues reopening is related.
Analysis of a projekt with approx 280 KLOC takes approx. 8-10 min. as a background task on the server. That's on subsequent analysis (i.e. not the first run).
Is this related to the above mentioned problem of issues getting reopened by the server?
Strangely enough, leak periods appear to work correctly, i.e. we correctly identify issues within the right leak period. I've not verified this in detail yet, but it's definitely not ALL old issues that get reported as open within the leak period. We only see old issues reappear, if the file that contains them has been modified - this activates all the other issues (from a previous version or leak period) within that file.
I've not specified any additional cmdline parameters for the SonarQube scanner during builds apart from the TFVC SCM plugin and path for coverage data.
We're using the VSTEST task v. 2 as otherwise it's not possible to collect code coverage in SonarQube when using TFS 2017 update 2 and VS 2017.
Please advise of any further data that I should supply to help this further.
Thank you for your help!
Somehow our TF builds stopped working. When triggered, the build stays within the queue and does nothing. The build was also triggered with high priority.
We have also checked the system events, but there are no TF related errors. We have also restarted the IIS site of the TFS - no success.
Any ideas?
I assume you've already checked to make sure your build agent is running. If so, there's a good chance you've run into a bug I've seen before. If this is the case, do you have the latest updates for TFS? If this is the bug I'm thinking about, it causes the build agent to appear "reserved" when it's not. Getting the latest updates should address that particular issue. I don't know what version of TFS and what updates you have.
I'm working in a project and I'm trying to optimize testing process so, when I execute a test case and I found a bug, I would like to associate this bug to the current build.
The builds are created automatically but when I try to select the built in the droplist there are not builds to select, so... How can I do it to get all the builds that I've made automatically?
Maybe is there any issue with Global List?
Im using VS 2010 and I have installed TFS 2010 Power Tools.
Thanks in advance!!
The global list is normally updated by an event subscription on the server that handles the BuildCompleted event. On your TFS server, there should be an executable named BisSubscribe.exe. You can use that to verify or fix the subscription. For more details, check out Jason Prickett's blog post on How to filter the Build Completion Event.