I have an existing pull request that I would prefer not to have to abandon and restart. There was no automated build set in the branch policy when the PR was created. However, I have since linked an automated build. Is there a way to make this change to the branch policies take effect without abandoning and recreating the PR? I've already shared and posted the link for the PR, so I was hoping I could seamlessly make this change apply.
Thanks!
It appears if you just abandon your pull request then reactivate it right away, that makes all new branch policy changes apply.
Related
I am working on a repo where I am the owner and only author in it.
I want to have in my repo the same behavior as I would when working with a team that protects my branch from direct commits as they must go through a Pull Request. The reason for doing so is to protect from my own mistakes as I sometimes go back to main branch and accidentally push code to it. I want only code that passed through a Pull Request to be able to be merged to main branch.
In order to achieve such behavior I added the following rule to my main branch -
Which is almost what I need, expect that I am locked without the ability to approve my PR's as there is a message I get saying authors of the PR can't approve their PR's - a logical error nonetheless, but if I am working alone in the repo this is not what I am looking for.
How can I achieve what I am looking for?
Simply disable "Require approvals" (the second checkbox in your screenshot), you will still be required to create a PR.
You can merge your own PRs, the only thing you cannot do is to approve your own work (after all: why would you? Hopefully you deem your own changes good!)
We are using Azure Devops to store our repo (Git) and run a pipeline.
The project type is .Net.
On recent PR that trigger pipeline, we noticed the pipeline failed because the developer removed a necessary file (PS script file).
Is there a way to prevent it -> somehow define that the pipeline will always "guard" some files in the main, and not let them be modified from other branches?
You can get really close to your goal by adding a branch policy called Automatic Code Reviewers based on specific files or directories. You can set the reviewer to a specific person or group of people, and any time a PR is modifying the "protected" file(s) the PR will not be able to be completed until one of those people approves the PR. If none of those people approve it the PR will not get completed. The nice thing about this is when you purposefully do wish to modify the file(s), you still can, but you just need to request that a certain group of people also approve the PR.
Tip: I recommend using groups for automatic code reviewers instead of specific people, even if the group has only one person in it. That way an admin can add/remove people from that group as needed, for example when certain people who normally approve the PRs are on out of office. It feels a little cleaner to adjust group membership temporarily, than to adjust the branch policies themselves on a regular basis.
I'm running builds with AzureDevops piplines. When I'm creating new pipline I'm not queueing it and just saving. If CI trigger is selected pipline will run if anything is checked in.
But on the very first run/chack-in pipline will be liked (associated) to ALL check-ins (changesets/commits) that happened before the current one and to all workitems of those chack-ins.
This behaviour is not desired for me. Is there a way to disable it?
On all subsequent check-ins build will be associated only with the one that triggered the pipline. And this is what I want for the first build as well, for it to be associated only with the chack-in that triggered it.
Without seeing exactly what's happening, it's hard to provide advice. It could also behave differently if you're using Git or TFSVC variants. Here's a few things to try:
Disable the CI trigger, do your first check-in, then re-enable the trigger. That might skip the change-set and work item affiliation one time.
Delete the offending build after it runs or do the laborious task of manually deleting all links in it.
If you're using Git, you can also limit the CI trigger by using a Pull Request with Squash merge. This will consolidate the commits down to one.
There isn't the way to disable it. It would compare previous run, then include all changesets between them. So, for first run, it must includes all previous changesets.
You may create a new branch for a folder, then configure build for that branch. Learn about branching strategies for Team Foundation Version Control (TFVC) and how to select an effective strategy
I'm pretty sure this setup was working at one point for us. I changed our builds a bit to reflect some operational changes and now the CI git branch trigger isn't working. I'm trying to get it so when a PR is merged into master it triggers the release build. I can trigger this build manually but not when submitting a PR to master from dev and then accepting the PR (on github).
Is anyone else having issues or know whats wrong?
Adding an answer so this more visible. #starain-MSFT comment was the solution.
I added a new build with the same trigger and it fixed the other one not getting triggered. Then deleted the new build I had added and everything is working.
Cloning my build definition didn't work, unfortunately, and neither did saving a trivial change to the build definition. Instead, I had to explicitly disable the CI trigger, save, then re-enable it and save it again. (Annoying, because I had to redefine all the rules.) But give it a try if the accepted answer doesn't do it for you.
I also wonder if adding a random branch to the triggering branches list, saving, then removing the random branch and saving again would work (and save you from having to redefine everything).
I want to fork a github project to fix a couple of issues and then send a pull request.
The problem I'm running into is that I've already forked the project to adapt it for another user base.
Is it possible to create a second fork? If so, how?
When I try to fork now it just takes me to the previously created fork.
There is no way to have two forks of the same GitHub project unless you use two different GitHub accounts.
So:
Create a separate GitHub account (and verify the email)
Fork the
project
Invite your main GitHub account as a "Collaborator" (from
the settings)
You may need to add the extra step of creating an organization with the new GitHub account and inviting your main github account as an owner of the organization (also make sure your new fork is in that new organization). This will let you do things like deploy automatically to a Heroku app that is connected to your main GitHub account.
Why can't we just have multiple forks???
I mean that I could just commit and push without making a pull request, but I want to do it the offical way and I want somebody else to review the changes before I push to a public project.
GitHub pull requests do not need to be submitted from a fork; they work within a single repository as well:
Pull requests are especially useful in the fork & pull model because they provide a way to notify project maintainers about changes in your fork. However, they're also useful in the shared repository model where they're used to initiate code review and general discussion about a set of changes before being merged into a mainline branch.
There's nothing stopping you from creating a pull request even if you don't technically have to. This is often considered a best practice, and GitHub's own Flow model is largely based on pull requests.
Creating a pull request within a single repository is very similar to creating one from a fork:
Create a feature branch and push your work to that branch on GitHub
In the GitHub web UI, switch to your feature branch
Click the "Compare" & review button
The trick is not to use the master branch to create pull requests. Then you won't need to create multiple forks since you can make as many branches as you need and make pull requests against each branch independently.
Given a clean forked repo, create a dedicated branch and use that branch for the pull request.
You can create branches from the web UI (although it is not obvious).
Click the branch selection dropdown, type the new branch name in the input field, and then you'll see a clickable link Create branch: <new-branch-name> as shown below. The tricky UI part is that it might not be very obvious you should click the "create branch: xyz..." — it is NOT displayed as a button or as a hyperlink, and there is NO indication that this is a clickable link. Moreover, there is NO hint whatsoever that a branch can be created until you type in the search box — anyone would probably assume that the search box is used exclusively for searching branches, and not for creating them.
In case you already made changes directly in your fork's master branch then consider moving those changes into a dedicated branch and hard resetting the master branch to the original remote so that you keep it clean for synching with the upstream repo.
See also:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository
The best way, recommended by github manual, is use command line git, mirror clone your repo and push it to your github.
https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/duplicating-a-repository
If you strongly prefer GitHub web interface to the command line, a GUI friendly workaround is create a new organization and fork to that new organization.
Another GUI way I can think of is to declare a fork as a template repo using repo's setting so you can create as many forks as you need.