I am using the online version of Coverity Scan for an open source project (rockowitz/ddcutil). The dashboard reports a small number of outstanding defects (8 for the current build), but the Outstanding Defects view doesn't show any. Does anyone have any idea as to the reason for the discrepancy?
I asked coverity about this issue and they said
"This is a known bug with the current release where ignored components seem to be counted. A fix is on it’s way later this week. Sorry for the inconvenience"
That was Tuesday last week
Did you define components to be ignored? I have a project that has 106 outstanding defects on the dashboard, but the graphs below show that many of these defects are either in system library headers, which I set to ignore, and in the unite tests, which I also ignore because so far coverity gave too many false positives and intentional errors. These defects do not show up on the Outstanding Defects view.
There seems to be a change of behaviour though, because some time ago, defects in ignored components did not show up on the dashboard.
Related
I've been trying to work with github-linguist for a while and it still gives a bit of problem.
After a few days of trying to figure out different issues with the language statistics, I managed to set .githubattributes with the right commands to get the correct statistics from github-linguist command:
But in GitHub's webpage/server it's still not showing up:
This is the link to the repo I am working on: https://github.com/FeriBolour/cotton-phenotyping
I tried different solutions:
Waited almost a week.
Pushed meaningless stuff to the repo to update the server.
It's still not working. What do you suggest me to do.
It could be two things:
It's not computing statistics on the branch you expect. GitHub only displays statistics for the default branch, but I believe locally you can compute statistics for any branch.
There's a bug on GitHub's side that caused the statistics update to be cancelled. I've seen that happen before while working on Linguist. I suspect it happens when the statistic-update job queue grows too large and jobs are dropped.
In your case, it's not problem 1 because you appear to have only one branch on this repository. It's most likely problem 2. You can contact GitHub support and they should have a way to manually trigger a statistic update for your repository.
I'd like to retrieve the number of closed issues in a repository.
With GET /search/issues?q=repo:tidyverse/dplyr+type:issue+state:closed I obtain:
total_count 3322
incomplete_results false
However here I can read that there are 3334 closed issue at the moment:
Why is there a difference of 12?
I've contacted GitHub support and they triggered a manual reindexing of the issues in this repository, so the search results are now consistent.
However they said that it can happen again:
Unfortunately this isn't a trivial issue, and although our engineering team are continuing to investigate this - we don't have a timeline on this being 100% resolved, 100% of the time.
In the repository https://github.com/JdeH/Transcrypt of the open source project I started, only 3 contributors are shown.
This seems weird, since many people filed issues, some pull requests etc. I myself, committing almost daily to the project, am only mentioned in June.
My own visibility isn't very important, since I am the intiator. But the fact that all the other contributions aren't honoured isn't good for the project.
It gives the impression that it is very "private", while we're working on it with a group of regular contributors.
What am I doing wrong? Why do only these 3 show up, one of whom actually changed only 1 or 2 chars at the start of the project, several years ago?
I've been looking everywhere, but didn't find an answer. Must be missing something very obvious!
Eric suggests that you read your team's diffs every morning. Can I get TFS to automate this in some way? Ideally I'd like an email with all of the differences in, but I'd settle for a link to each of the commits.
As someone who works for Eric and who has the behaviour of checking the diffs each morning let me explain what I do. I'd like to think that I was one of the people he was thinking about when he wrote the post, but I know for a fact that he didn't know I did the diff checking each morning :-)
In Eclipse I use the Team, Synchronize... functionality to compare my local workspace with the latest on the server. As I do a get latest frequently, this tells me what has happened since I last did this (i.e. what changed while I wasn't looking).
In Visual Studio, I can do a similar thing by right clicking on the root folder of the area that interests me and selecting Compare... and then doing a compare of the Workspace version with the latest version.
Alternatively, you can just do a "History..." on the folder that is of interest and a brief scan down the history view will show you what has been happening and you can go look at what is interesting. It also encourages you to leave good check-in comments, and to encourage your developers to do the same :-)
I used to have email alerts configured for each check-in (Team, Project Alerts...), but I just ended up ignoring them most of the time. I even have a robotic rabbit configured to talk to me when someone does a check-in or runs a build - but this is only useful during the day, not checking what has happened the previous day while I was asleep (I live in a different time-zone to the rest of my colleagues so they do a lot of work while I sleep and vice-versa, making the practise of diff-checking even more useful)
In theory it would be possible to write a program that did generate you a diff each day between the latest version and your workspace version, however I've never bothered myself. This is partly because as I find the most value of the practise comes in exploring the changes that were made each day rather than just reading about them. I also admit that I wasn't aware that anyone else in the world was doing this daily diff routine - I figured I was alone in my code voyerisum, but obviously not!
UPDATE Feb 12, 2009: The following blog post just came to my attention.
http://blogs.msdn.com/abhinaba/archive/2008/07/07/auto-generating-code-review-email-for-tfs.aspx
It talks about (and provides source for) a tool called CRMail that will generate an email from a shelveset that will contain links back to Team System Web Access to show the diffs for each change in the changeset. It would be possible to modify this source to get it to show you diffs between changesets if you wanted to. Then you would just need to hook it up to run either as a nightly scheduled task or on every check-in by subscribing to the check-in event from TFS.
Have you explored setting up a report on the project portal that would show diffs based on date? I haven't done this (and I'm at home now so I can't investigate it), but I know that there is a lot of information you can get out of the portal. Whether you can get code diffs, I don't know.
The other alternative would be automating something with tfsadmin or the power tools. Again, not at work so I can't look at it, though the power tools seem like they may make it possible to do what you want from the docs.
A quick solution would be to configure project alerts to send you one email per changeset.
Filter these into a separate folder in your email client, and review them at your leisure.
I have a set of work items that are completed and I am ready to move their changes to our production branch. Is it possible to find the changesets that are attached to them and selectively merge them with the target branch?
Not easily is the short answer.
Currently there is no real link between work items and code promotion. You can associate a changeset with a work item on check-in (or indeed at any time), but that is about as far as things go.
Basically you would have to do this by hand using the provided UI in Visual Studio (i.e. look up the work items, get the changeset ID's and then do (possibly several) merges by selecting the appropriate changeset ranges. If this is a regular way of working then you could write a program in .NET that used the Microsoft TFS API to talk to the work item tracking component to get the changesets required and then either did the merges programatically or kicked off the command line client (tf) to bring up appropriate UI for the merges.
Sorry it's not a more helpful answer. I know that the team at Microsoft have heard this scenario a few times now however I've not heard of any plans to have it better supported "out the box" in the current or the next release of TFS. That said, there are a lot of improvements to the branching ad merging stuff in TFS2010 so it is possible that something is/will be in there that might help you. It may be worth you logging some feedback on http://connect.microsoft.com/VisualStudio for this feature if it is important to you.
Good luck,
Martin.