Results 1 to 6 of 6

Thread: Master to Master Azure DevOps

  1. #1

    Thread Starter
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    39,142

    Master to Master Azure DevOps

    I'm using DevOps for source control on some projects for which I am the sole developer. In the last couple weeks, I've gotten a couple strange failures when pushing to remote. The error message is this:

    Error: master -> master (TF402455: Pushes to this branch are not permitted; you must use a pull request to update this branch.)

    followed by:

    failed to push some refs to (the right URL).

    After looking around on the internet, I found various references to this, but none of them seemed quite applicable. What I can do is branch the repo, push the branch, then merge the branch back to master, but this is only for a few projects. Some projects have no problem pushing to master, others no longer allow it.

    I'm pretty sure I could wipe the repo out of DevOps, build a new one, and push that. Losing the history wouldn't cause any real issues for these particular projects, but it's annoying.

    What I'm looking for is both a way to solve this without delete and replace, and perhaps a suggestion as to why it started happening?
    My usual boring signature: Nothing

  2. #2
    PowerPoster PlausiblyDamp's Avatar
    Join Date
    Dec 2016
    Location
    Pontypool, Wales
    Posts
    2,544

    Re: Master to Master Azure DevOps

    The only time I have seen this is when the master branch is protected by a policy. Have you checked to see if one has been set? Sounds a bit insulting to ask really...

  3. #3

    Thread Starter
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    39,142

    Re: Master to Master Azure DevOps

    Everything I found suggests that this is policy related, as well. To put it lightly, there's some monkey business going on around our Azure DevOps, so it's entirely possible that somebody did something without telling me (or anybody else, for that matter, which makes figuring out who to ask pretty tough). Heck, if somebody set a policy, folks are so new to DevOps they may not even know what they did or what impact it would have. Still, from what I can see regarding the policies, there doesn't appear to be anything there. There don't appear to be any policies set at all. I may not be seeing all there is to see, though. Our setup is.....strange, and characterized by a certain lack of communication.

    The other argument against that, though, is that I'm now having issues with only two repos. The others that I have pushed to (admittedly only a further two, one of which was created after this issue was first discovered), have had no issues. It seems to be a per-repo issue, and per-repo is how I can view policies.

    I'll have another look, though. I'm pretty new to DevOps, as well. I use GitLab, primarily, but my whole organization moved over to DevOps, and as people learn new features, things just keep on changing.
    My usual boring signature: Nothing

  4. #4

    Thread Starter
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    39,142

    Re: Master to Master Azure DevOps

    I got on to other things, but found this issue rearing it's head again on a couple different repos. Still doesn't seem to impact all of them, though, which is really odd, especially since I kind of maybe, possibly, solved it?

    I got looking through all the settings, again. Azure DevOps has layers and layers of various settings for various things. I really only use it as a source control solution, though our team is using other features of it more and more. Still, I only need a portion, so some of the settings are areas I hadn't wandered into.

    Every setting I found about pushing sure looked like it was set the way it should be. I could limit merges to the branch, but there are four types that can be toggled, and all four were on. That seemed unlikely to change anything, but I turned off the ability to limit merges. That move changed the behavior, but not in a good way. The push was still rejected, there just wasn't any hint as to why anymore. All I saw was "see the output window for more information", but that's all that was in the output window. Turning the ability to limit merges back on restored the state. The push failed, but now I had a reason in the output window.

    That didn't seem to be the answer, so I got looking around for other settings. The one that I found that worked was allowing bypass policies when pushing. That suggests that there was a policy to bypass, but what that policy was, or where it could be found, I have yet to determine. Interestingly, bypassing policies when pushing wasn't denied, previously, it was just not set. This suggests that nobody in the organization has paid any attention to this in the (very brief) past.

    Can anybody tell me where I could see the policies that I was bypassing? They only appeared to impact certain branches of selected repos.
    My usual boring signature: Nothing

  5. #5
    PowerPoster PlausiblyDamp's Avatar
    Join Date
    Dec 2016
    Location
    Pontypool, Wales
    Posts
    2,544

    Re: Master to Master Azure DevOps

    Quote Originally Posted by Shaggy Hiker View Post
    I got on to other things, but found this issue rearing it's head again on a couple different repos. Still doesn't seem to impact all of them, though, which is really odd, especially since I kind of maybe, possibly, solved it?

    I got looking through all the settings, again. Azure DevOps has layers and layers of various settings for various things. I really only use it as a source control solution, though our team is using other features of it more and more. Still, I only need a portion, so some of the settings are areas I hadn't wandered into.

    Every setting I found about pushing sure looked like it was set the way it should be. I could limit merges to the branch, but there are four types that can be toggled, and all four were on. That seemed unlikely to change anything, but I turned off the ability to limit merges. That move changed the behavior, but not in a good way. The push was still rejected, there just wasn't any hint as to why anymore. All I saw was "see the output window for more information", but that's all that was in the output window. Turning the ability to limit merges back on restored the state. The push failed, but now I had a reason in the output window.

    That didn't seem to be the answer, so I got looking around for other settings. The one that I found that worked was allowing bypass policies when pushing. That suggests that there was a policy to bypass, but what that policy was, or where it could be found, I have yet to determine. Interestingly, bypassing policies when pushing wasn't denied, previously, it was just not set. This suggests that nobody in the organization has paid any attention to this in the (very brief) past.

    Can anybody tell me where I could see the policies that I was bypassing? They only appeared to impact certain branches of selected repos.
    I am not aware of a single place to view branch policies, in the past I have always just gone into the Branches section of Repos and checked each branch individually. Normally not an issue as I tend to use a Feature Branch workflow so I have very few branches and only a couple of long term ones.

  6. #6

    Thread Starter
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    39,142

    Re: Master to Master Azure DevOps

    After a bit of discussion with other people who may have more understanding on how we sort of have Azure DevOps set up, I think I ran afoul of something that I can't even see. It's an odd situation, and not one that is worth explaining all the intricacies and politics around the way this thing is set up, but the bottom line is that nobody I work with, or even in my organization, is in control of how this was/is set up. I've found an acceptable workaround, but it's just that. The situation is too bizarre to be fully manageable. Settings like policies can be changed without notice, accountability, or transparency. I think that happened, it's just too opaque to be sure.
    My usual boring signature: Nothing

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width