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.
Related
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!
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
I have a Mantis bug tracker installed that we use for all of our products. One product goes through a rapid development cycle and each new build gets a new version number (the build number is incremented). Since our QA has to report all bugs they found for the build that introduced the bug, we also have to add a new version number to Mantis every time a new build is made. Because of this, the list of version numbers under Manage->Manage Projects->Project name is now very long.
I just tried to delete one of the very old version numbers but that removes that number from all issues that referred to it. (Makes sense from a DB design point-of-view.)
Is there a way to shorten the version list without affecting the issues? The very old version number we have will never be used again but I want the old issues intact. I did a bunch of Google searches but I keep getting flooded with unrelated results.
Did you try to set the obsolete attribute of version ?
As said in the admin guide :
Each project can have several versions, which are marked with attributes like released and obsolete.
and :
Once a version is marked as obsolete, it is now longer included in the change log.
See also these issues :
Obsolete versions not selectable as filter in `View Issues'
Versions marked as obsolete appear on change log page
If I understand you properly, what you'd like is a way to filter the versions displayed in the Manage Projects page.
This cannot be done in current version of MantisBT (1.2.14), and would require a change in the code. I suggest you open a feature request on our tracker. If you end up implementing the feature, then submit it as a pull request on our Github repository.
I'm developing a CI (Continuous Integration) for my application.
So, I'm using Jenkins with HockeyApp (equal to TestFlyApp).
The problem is that HopckeyApp only accepts new versions of an application if it different versions from the last one added, else it gives me an error of already existing version, and no update.
I was reading about the apple tool Agvtool to update the value CFBundleShortVersionString.
My main problems are,
how to do this in Jenkins automatically.
How to update the project repository (Git in my case),for the next build it knowing which is the last version that was updated, or any other option to keep track of the last version updated.
I am trying to do this, but other approach will be accepted has well.
Thanks in advance.
It is recommended to update the CFBundleVersion and not the CFBundleShortVersionString, see http://support.hockeyapp.net/kb/how-tos/how-to-do-versioning-for-beta-versions-on-ios-or-mac
The following blog posts goes through the whole setup and also shows how to automatically update the version number using git tags: http://monitzer.com/?p=75
Here is another approach using git to update the version number: https://gist.github.com/3395649
How do you version in JIRA when your versions are like 4.8.{TFSBuild}.{TeamCity.Build}?
Do I simply create a 4.8 Version in Jira?
However what would I set the release date to?
The problem is that our versions are dynamically and created based on the build# from tfs and the Team City build#.
What is now the best way for me to create versions in Jira?
Only the Major. Minor is hardcoded for now and for every few bug fixes we upload the release to the live server.
Jira versions are primarily a planning tool (especially if you use Greenhopper aka Agile, where you can have a version hierarchy).
So that's different from a build. It may take a thousand builds to achieve the functionality planned for a "FixFor" version.
On the other hand, "Affects" versions are used to track in which build a particular bug was found. So it'll pay to rename the "current version" (when you mark it as Released) to the actual build, as Hugo suggests. And cleanup/close/move any outstanding issues at the same time.
I would suggest to name the upcoming version that doesn't have a fixed name yet something like "Next release".
When you actually do release that version then you can change the version name in Jira to reflect the correct name.
Using Jira For Project Management - Creating Versions
We use Jira for project management of daily task assignment and we like to have versions either by week or by month. This lets us assign work for a week and is very helpful with the Greenhopper plug in. Basically, you:
Open the project from "Projects"
On left side, click on "Versions"
We have version 4.4 so might be slightly different other Jira versions.