I'm using Sonarqube with the Github plugin for analysing code in Pull Requests.
I get a problem when pushing code if the PR is already open. The comments made by the Github plugin in the PR are erased even if the new push doesn't fix them! Apparently because only the modified code gets analysed, and the other comments by the issue reporter user are erased. It means I'm losing the previously reported issues.
Any ideas on how to maintain the comments for the issues I still haven't solved in new commit/pushes?
The way I solved this problem was to make some additional changes on the files in my first commit.
This happened to me also. I had 1 commit when I opened the pull request, tons of issues were noted. I made a second small commit to update an unrelated configuration file, this caused sonar to remove all of the comments. I tried everything I could think of to get it to scan the full pull request: Closed/re-opened the pull request, ran the sonar preview scan again manually, reverted my 2nd commit (which created a 3rd commit).
We have git send us email reports of any comments made on our pull requests, so we had a record of all the sonar comments. We made some changes to the original files based on these comments and once we committed our fixes, sonar ran against the original files and the rest of the sonar comments popped back up!
This created a new best practice for us. If sonar finds any issues, the next commit should be fixes for those issues.
Related
Im working with a team in a repository in GitHub (we are many collaborators), but Im always having merge conflicts in my command line in Visual Code every time I finish working and want to push my changes. And recently got into GitHub and saw another member's name in my branch but I don't remember what else the message said- The member said that they were only looking at my commits bit didn't change anything. However, I wonder if that member going into my branch may have causes some sort of problem that I couldn't commit any of my work. Any ideas? Thanks!
I have a PR where I left several comments in my review on GitHub
A colleague has updated the code to apply my suggested changes, and now all my review comments appear with the outdated label.
However I still see the code in the state it was when I commented it.
What I want is an easy way to see the new code he has written, not the old. Is it possible at all?
Open the PR and Click on the files changed tab. All the latest changes that have been pushed to the branch requesting the PR will be available.
I would like to know the best way to undo a pull request made to the main branch on my GitHub repository.
Context: I don't have a staging server and did everything I could to test some new changes locally, but I missed a few things and want to roll back the merge to add to it before deploying again.
I tried "revert" and I believe this has successfully reverted the changes. I then made a handful of additions and then created a new pull request however GitHub is suggesting the only differences between main and the dev-branch are the latest handful of additions: it does not include all the prior differences between main and the dev-branch.
EDIT (additional context in response to comment): To summarise the overall sequence... I finished work on a branch, created a PR, then merged it to main. When testing on the remote server (production as I don't have another) I realised there was further work required. I wanted to rollback to prior to the merge and used "revert" in GitHub on the web. This does seem to have reverted the changes, but I expected that if I resumed work on the branch (which I hadn't deleted) and then did a subsequent PR when complete, that ALL changes would be included (ie the new changes PLUS the previous differences between the branch and main). This isn't the case... seeimgly only new changes are shown in the diff.
Is there a way to make bitbucket show commit messages as part of comments/activity related to a specific issue, whenever it's been marked-up in said message; the same way github does?
Thanks.
Issues, pull requests, users and commit hashes can be linked in BitBucket issues and commit messages.
Issues can be closed automatically by including something like resolves #123. Commits referencing issue 123 will generate a cross-reference in the issue. This relies on the issues hook to be enabled, which is done by default on new (after August, 2012) issues-enabled repositories.
A little more specific to this, as I had the issue where I was putting issues into my commits, ala "issue #89" which gave me links from the commit into the issue, but not vice versa. Finally found that only a specific set of commands would cause the issue to cross-reference to the commit. This issue led to this guide of actions:
so if I use "ref bug #89", then I got the links and cross referencing in the commit and issue i was looking for.
I'm fairly new to Mercurial so I'm hoping someone can help me as I'm currently close to tears ;)
So I've been working locally and committing to my local repository. I wanted to push my changes to the server so I first pulled the latest changes. All ok so far.
I then tried to do a push but got the following error:
[Error: abort: push creates new remote head 80394c55f2dc!]
new remote head 80394c55f2dc
[Error: (did you forget to merge? use push -f to force)]
I then read that a pull doesn't merge the changes into my local repository.
I loaded up Workbench so I can now see my changes and the other dev's changes that have been pulled. I then did a merge on the other dev's most recent revision.
I now have two rev 112 one with a description of Merge and 112+ which says * Working Directory *
I hope I've explained this properly and I can provide screen shots if required but I'm slightly stumped.
I just need to get all changes merged and pushed.
Here's a blog post that does a decent job of explaining what you need to do. The fifth image in the post matches your situation, based on your description. In addition to revision 112, you probably have another head at another revision. You will have to click on that head and then select Merge with Local from the context menu. TortoiseHg will then guide you through the process of merging these two heads. If you do not have to intervene at all to resolve any conflicts, you will end up with a dialog with a default commit message (Merge) for the new changeset that represents a merge of the two heads (one of which came from your work and the other that came in when you pulled).
The Mercurial wiki has a nice page that should help you get comfortable working with Mercurial. I am sure you will do just fine :)