We have a PR release process (classic) that runs tests and posts a status when it completes. PRs without conflicts are completing and merging in successfully, but PRs with conflicts are failing to merge since last week.
After resolving conflicts and the PR release starts, it will run through and a green tick will eventually be shown on the PR page. When we go to complete the changes, DevOps detects some kind of change and reverts the posted status.
The below messages appear when trying to complete (nobody has again tried to resolve conflicts):
conflict message
It seems there's something DevOps doesn't like when it tries to merge but I can't figure out what it is.
We have tried:
Merging the pull request branch against the target on my local machine - all is OK, no errors raised.
Turning this setting off and it works:
repo setting
but we want to keep this on.
We could also rebase but we would rather not have to enforce this.
Related
I'm doing all of my configuration locally, and pushing the json files.
I'm having all kinds of issues with ADF not noticing the changes, or only noticing some of the changes.
I changed the linked service name, for example, pushed the branch, and then in ADF tried to trigger a deploy. I got errors with the old service name.
I waited a while, changed branch back and forth in ADF, hoping it would refresh somehow. After a while I tried again and it partially worked, it got further into it but then the same issue occurred, one of the table migrations I set up gave a credentials error and I could see it was trying to use the wrong connection again.
I double checked the JSON and it was definitely using the wrong connection.
This is a recurring issue. I've tried hitting the button to force changes from the branch but it says nothing to update. The problem is recurring a lot and is very annoying.
Is there any fix for this?
Whenever we create a pull request from local branch, make sure that branch is the newest branch that is just made to push the changes.
You can Work on the development in your local branch, but meanwhile there can be people working on other branches and pushing there changes which can conflict with your local branch.
So download the pipeline suppport zip file which is developed and tested and copy it in a new branch and push your changes and delete the new branch. This will avoid the conflict.
So you know it's common in team where multiple people are working on same project. Now when you have done your work and you push it to Github, it triggers the approval process.
Before your commit gets approved, if someone else also pushed changes and his commit (if) got approved earlier, then Git will say your branch is out of date & you will need rebase it.
Now if someoe else had already approved and you were waiting for merge, but due to in-between commit you have to ask for approval again, is there a way to fix it?
Although that commit didn't conflict any of your files.
I am working in my local branch-1 and my colleague works on his local branch branch-2.
He already committed and pushed the branch to his origin/develop and created a Pull request to upstream/develop. So now it is waiting for review and approving the pull request by someone else.
The problem is, in my local branch I need to edit one same file, which my colleague worked on. So my branch and his branch will containe the same file with different code. If his branch would be already in upstream, then I could merge it to my branch and resolve the conflict locally without problems.
However now it is in Pull request status waiting for review and I don't have time to wait, I need to create also my Pull request.
How and when will the conflict be solved, as the file with conflict is in both pull requests now, will git recognize it now or? As those branches are not in upstream yet.
Whichever branch is merged first, the other PR will have a merge conflict that must be resolved. If yours is merged first, theirs will suddenly have to fix a conflict. If their PR is merged, yours will have a conflict.
The PR main page will show the conflict and won't allow it to be merged.
The other answer is the correct one, but I want to add another possible course of action.
If your two separate features need to follow (for whatever business/architecture related reasons) merging order, where branch-1/feature-1 must be before branch-2/feature-2 and also at the same time, you need to create a PR for your feature, then what you need to do is rebase your branch on top of your colleagues branch and create a PR that way.
Once branch-1 is merged, then rebase branch-2 onto the latest upstream/develop. This will force you to resolve conflicts and update the PR accordingly.
We are using Gitlab (the gitlab.com free version). My colleague is creating merge requests and we are merging from one branch (development) into another (master). When my colleague merges into master the MR is shown as Merged. I am then running some tests on the merged branch (not done automatically through GL currently) and when happy with the merge I am wanting to close the merge request. However I do not have any option to close it - I do not have a close button and if I type /close in the comments it does not do anything.
Neither my colleague or myself are able to close the MRs. We both have Master status and have tried changing various MR project settings but to no avail.
PLease can anyone help?
In Gitlab, the merged status means the relevant commits have been merged and no action is needed.
A closed merge request is one that has been put aside or considered irrelevant. It is therefore not merged into the code base.
Therefore, you only merge MRs when you're happy with the changes and close them if you think the changes are not worthy of being integrated into the code base ever.
A typical workflow would be the following:
User A works on a new feature in a feature branch and pushes their work to that branch.
They can open a merge request to merge their feature branch into master.
User B pulls the feature branch, eventually rebasing it onto master, and runs the tests they want.
If User B is happy with the changes/new feature, they can merge the MR into master (or whatever branch you merge into)
The merge request will be shown as merged
Of course it's better if the tests run automatically in a CI.
With GitLab 12.2 (August 2019), you have new options which could help indicate the "closed" status of a merge request.
See "New push options for merge requests"
In GitLab 12.2, GitLab has been taught new push options to:
Set the branch to be removed when it is merged.
Change the merge request’s title.
Change the merge request’s description.
See issue and documentation
We are hosting a c/c++ based repo with multiple branches in Github , while doing CI , there are usually on the average 10 pull requests in each integration build , and if something fails , we have to track it in all of the merged PRs to figure out which one did the mess , i want to work it programaticaly so that i can know which pull requests fails the build. What can be the best approach to work on this problem.
One thing that i forgot to mention is that each PR is individually build and tested already before the merge into feature branch.
Thanks.
The best approach is to change your process a bit and only allow merging of Pull Requests that:
Build without errors (including running integration tests)
Are rebased to fit on the tip of your master branch (fast forward commits only)
Since the branch build without errors, and it was rebased on the latest master, merging it will never break master. Unrebased branches that are seemingly without conflicts can still break things if changes in not directly related files conflict with each other as the conflict algorithm is pretty simplistic.
Lacking that, git also has an option that can be used during an interactive rebase to run a command (the exec option) after each rebase step. In other words, you could rewind your branch back to a known working state, and then let git apply each commit in turn and run a command that checks if everything passes your tests with the exec option.
In this way you can automatically discover which commit broke your tests.