Remote error at least 1 approving review is required by reviewers with write access

remote: Resolving deltas: 100% (5/5), completed with 5 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/master.
remote: error: Required status check "Travis CI - Pull Request" is expected. At least 1 approving review is required by reviewers with write access.
To https://github.com/*****
 ! [remote rejected] master -> master (protected branch hook declined)
error: failed to push some refs to 'https://*****'

2

Содержание

1. push to protected master branch without admin permissions #205
2. Comments
3. Footer
4. Requiring Pull Requests and Reviews in Your Git Workflow
5. Outline What is a pull request? If you’ve been using Git for any substantial amount of time then you have probably at least heard of pull requests. However, pull requests are not necessarily an integral part of everybody’s Git workflow. You could use Git/GitHub for years and never once have to create/merge a pull request. A pull request isn’t really anything special. If I have been working on a branch in the repository, and I push that back up to the remote branch on GitHub (or wherever), a pull request is basically a formal method to say: «Hey, I’ve got some changes over in this branch I want to merge into the main branch» Creating a pull request will allow you to review the changes that will be included and make comments about the pull request for the person(s) who will be reviewing that pull request. This then creates a more formal environment where the changes can be reviewed/discussed, and if necessary you (or others) can push further changes to that branch which will also be included in the pull request. A pull request can then be merged into the main branch either directly through Github (just by clicking a button), or by checking out the pull request locally and merging it using the command line (this will be required if there are merge conflicts that need to be resolved). NOTE: We are talking about a shared repository model in this tutorial where multiple contributors all have push access to the same shared repository. Pull requests are also heavily used in open source software where you might typically fork a repository you don’t have push access to, make some changes in your own fork, and then create a pull request to request changes from your fork be included in the original repository. Why do we want to use pull requests? As I mentioned at the beginning, there is nothing stopping any contributor in our repository from just pulling down the main branch and pushing right back to it. This violates the task branching model we are trying to follow, and we just have to hope that people follow the rules. Even if people do make a good faith effort to follow the rules in general, there will almost certainly be times where these rules are violated. Although this will be our main motivation for enforcing that pull requests are used, using pull requests and reviews is also just a good idea from a collaboration and code review perspective. Enforcing pull requests Making a pull request required for merging into the main branch (or any branch) is quite easy with Github. Let’s do it now. Go to Settings > Branches Click Add rule on Branch protection rules Add main as the Branch name pattern Now you can set whatever rules you want. We are going to add the following rules: Once you have enabled the rules you need, you just need to click Create . NOTE: If you are the only person working on this repository you should not check the Include Administrators option. You can not review your own pull requests, so you will need the ability to bypass the review requirement. Unfortunately, this will also allow you to push directly to the main branch so it defeats the purpose of doing this in the first place. As I mentioned, I still think it is a good idea to set up and follow this process as if it were required, but just know that your admin privileges remove the protections we are putting in place. An example of the workflow with pull requests Let’s see what our workflow looks like now. One of our main goals here was to stop people from pushing changes directly to the main branch. Let’s see what happens if we accidentally worked on the main branch and tries to push it: git checkout main git commit -m «pushing straight to main» NOTE: If you have not set the Include Administrators option mentioned above the push to main will work. Perfect, our push was rejected. Realising our error we might now want to move our commits onto a new branch. First, we will create an issue for the branch we are creating: NOTE: Creating an issue isn’t actually enforced. Then we will create a new branch that references that issue (using the branch name format we discussed in the first tutorial in this series): BONUS TIP: Moving work committed onto the main branch to a feature branch Since this branch was just created from our local main branch it will include the changes that we committed to the main branch. This allows us to carry our work over to this new branch. However, if this branch already existed then this would not work. If we already had a branch called jm-15 , and we wanted to move commits from main to our feature branch, then what we could do instead is on the main branch run: To view the most recent commits. Make a note of the hash of each commit that you want to move over to the existing branch, e.g: NOTE: Type :q to exit the editor Then you can change back to your existing feature branch: and pull those commits into the feature branch using cherry-pick for each commit that you want to keep: To remove the commits from the main branch and get that back into a fresh state from the origin, you can just run: This will remove any staged commits and destroy your local work. If you switch between main and jm-15 now, you should see that main does not contain any changes and jm-15 does, which is what we should have done initially. Creating and merging a pull request Ok, we have our new work in its own branch now, which we were forced to do by the branch protection rules that we created. Now let’s see how we actually go about getting our changes merged into main . First, we will need to push our changes up to the remote repository: NOTE: —set-upstream origin jm-15 is only required if this is the first time you are pushing the branch to the remote repository (i.e. the branch does not exist in the remote repository yet) If you go to Github now you will see a notice like this: You can just click Compare & pull request here but that notice won’t be displayed forever. You can also create a pull request by going to the Pull requests tab and then clicking New pull request. You will want to set the base to main (or whatever your main branch is called) and the compare to jm-15 (or whatever the branch you are merging is called). You will then be able to review the changes: Once you are satisfied, click Create pull request. You will then be given the chance to add a comment, and then you can click Create pull request again to actually create the pull request. Then you will see a rather intimidating screen like this: The status checks aren’t actually of any concern to us here as we haven’t enabled status checks in our branch protection rules (we will likely cover that in another tutorial). What is blocking us at the moment though is the need for a review: To review a pull request you will need someone (who is not the person who created the pull request) to: Open the pull request and click on the Files changed tab Click Review changes Leave a comment, check Approve , and then Submit review Back on the main pull request page, click Merge pull request NOTE: You can not not approve your own pull requests, so if you are working on the repository by yourself you will need to bypass the review restrictions by just clicking Merge pull request without submitting a review. The Include administrators option under the branch protection rules must be disabled in order to allow this. And we are done! Summary We all make mistakes, and wherever possible we shouldn’t rely on people manually following processes and following the rules. If mistakes from developers end up negatively affecting our codebase or product, then we should see it as a failure of our processes not of that developer. If we can use tools to help enforce the software development process we want to create, and protect/guide our developers in the process, then we should absolutely do that. It creates a much less stressful work environment for all stakeholders if you know there are safeguards in place. Источник When using protected branches (1 peer review) auto fails #1491 Comments Describe the bug We have protected branches branches turned on to ensure To Reproduce Add «Require pull request reviews before merging» Expected behavior Auto should deploy, bypassing the branch protections. Screenshots Environment information: Additional context Settings: The text was updated successfully, but these errors were encountered: Another option is to use a PAT instead of the gh action’s token. We are using a PAT. We were using the wrong token 😅 I 🙏 it works lol This isn’t really an Auto issue but rather a thought-out limitation of Github Actions: Yes I agree that it isn’t autos issue, but given auto have a deep relationship with Github it should be considered. I like the automated merge PR. Seems like it’s something that an auto plugin could support? If protected branches is enabled then create a release PR rather than pushing to master. Additionally, it could utilize the API to use the associated admin permissions granted through the PAT to merge the release PR. If protected branches is enabled then create a release PR rather than pushing to master. Currently this would be a little more work than that. Each plugin is responsible for pushing the changlog/version commits. To make this pluggable we would need: to move that behavior into core make a new hook for pushing the release make a plugin that uses that hook to do what you described I kind of like what https://github.com/benjefferies/branch-protection-bot does. this would be easier to do via a plugin: Turn off branch protection during the afterVersion hook Turn on branch protection during the afterPublish hook Just gotta find the right octokit API It surely will work, but it seems precarious and potentially problematic for orgs that have strict controls around branch protection. I scanned through the plugins and I see what you mean. Instead of moving the changelog / version to core what if there were different types of plugins. For instance if the conventional-commit plugin was broken into two plugin types: conventional-commit-changelog and conventional-commit-version. If I want to use conventional-commit changelogs, but use github labels for my versioning I can. Possibly, a much larger conversation, but I’d be interested in assisting in developing a more robust solution which would satisfy various org requirements. It surely will work, but it seems precarious and potentially problematic for orgs that have strict controls around branch protection And if it the publish were to fail the branch protection rules would be lost 😢 The work to move the tag pushing into core looks like: Move all git push —tags calls from publish hooks to after this line Examples of git push —tags calls: Looking at this more it might be tricky finding all the places where we would push a commit to the baseBranch to switch to the PR flow you described. Create a new hook called something like push that’s a bail hook Set up the default behavior to just do the push Create a plugin (as a package or internally) that overrides the default behavior and makes the PR So I’m gonna close the PR I made to do this in a plugin as it seems to brittle. I’d be willing to accept a PR for this but it also seems like a pretty big lift. Although I had planned on moving the tag pushing into core at some point to facilitate #917 Possibly, a much larger conversation, but I’d be interested in assisting in developing a more robust solution which would satisfy various org requirements. feel free to discuss this here! I’ve made changes to my PR that will re-enable the Peer Reviews even when something in auto throws an error. So this should be a little less brittle now. So the only way this wouldn’t work now is if: you don’t have permission to change this setting you hit the «merge quickly» window perfectly (low chance and i’m pretty sure the first one would abort before any weirdness) As for the PR method you are describing. It goes pretty far out of the way of auto ‘s normal workflow. The biggest pain point I can imagine is that since you would be pushing tags to branches there would be a possibility of multiple PR merges creating branches with conflicting tags. We could write code that makes sure we only have 1 of those PRs up at a time but I feel like there would be some edge case weirdness to deal with. What’s weird is that this works fine for me on GitHub enterprise. On enterprise we use a dummy «bot» account with admin permissions to do this. Locally on my test project i’ve made a key with all permissons and it still doesn’t work at all. That is strange. We don’t use Enterprise at my org, but I have experienced the same issue on our (teams?) account despite being an Admin or using our dummy account which is also an admin. I need to look at how our Buildkite jobs do this. Maybe they found a trick that works. I’m going to formalize my thoughts and post about it tomorrow. Thanks for your attentiveness and support. All sources point to a token from an admin with the right permissions should fix this. I’m trying this on this repo to no avail. what’s weird is everything works fine locally using the same exact token. I can push directly to master but the same token doesn’t work in CI I’m in contact with someone who works at github and there might be a fix to this coming out at some point Источник
6. What is a pull request? If you’ve been using Git for any substantial amount of time then you have probably at least heard of pull requests. However, pull requests are not necessarily an integral part of everybody’s Git workflow. You could use Git/GitHub for years and never once have to create/merge a pull request. A pull request isn’t really anything special. If I have been working on a branch in the repository, and I push that back up to the remote branch on GitHub (or wherever), a pull request is basically a formal method to say: «Hey, I’ve got some changes over in this branch I want to merge into the main branch» Creating a pull request will allow you to review the changes that will be included and make comments about the pull request for the person(s) who will be reviewing that pull request. This then creates a more formal environment where the changes can be reviewed/discussed, and if necessary you (or others) can push further changes to that branch which will also be included in the pull request. A pull request can then be merged into the main branch either directly through Github (just by clicking a button), or by checking out the pull request locally and merging it using the command line (this will be required if there are merge conflicts that need to be resolved). NOTE: We are talking about a shared repository model in this tutorial where multiple contributors all have push access to the same shared repository. Pull requests are also heavily used in open source software where you might typically fork a repository you don’t have push access to, make some changes in your own fork, and then create a pull request to request changes from your fork be included in the original repository. Why do we want to use pull requests? As I mentioned at the beginning, there is nothing stopping any contributor in our repository from just pulling down the main branch and pushing right back to it. This violates the task branching model we are trying to follow, and we just have to hope that people follow the rules. Even if people do make a good faith effort to follow the rules in general, there will almost certainly be times where these rules are violated. Although this will be our main motivation for enforcing that pull requests are used, using pull requests and reviews is also just a good idea from a collaboration and code review perspective. Enforcing pull requests Making a pull request required for merging into the main branch (or any branch) is quite easy with Github. Let’s do it now. Go to Settings > Branches Click Add rule on Branch protection rules Add main as the Branch name pattern Now you can set whatever rules you want. We are going to add the following rules: Once you have enabled the rules you need, you just need to click Create . NOTE: If you are the only person working on this repository you should not check the Include Administrators option. You can not review your own pull requests, so you will need the ability to bypass the review requirement. Unfortunately, this will also allow you to push directly to the main branch so it defeats the purpose of doing this in the first place. As I mentioned, I still think it is a good idea to set up and follow this process as if it were required, but just know that your admin privileges remove the protections we are putting in place. An example of the workflow with pull requests Let’s see what our workflow looks like now. One of our main goals here was to stop people from pushing changes directly to the main branch. Let’s see what happens if we accidentally worked on the main branch and tries to push it: git checkout main git commit -m «pushing straight to main» NOTE: If you have not set the Include Administrators option mentioned above the push to main will work. Perfect, our push was rejected. Realising our error we might now want to move our commits onto a new branch. First, we will create an issue for the branch we are creating: NOTE: Creating an issue isn’t actually enforced. Then we will create a new branch that references that issue (using the branch name format we discussed in the first tutorial in this series): BONUS TIP: Moving work committed onto the main branch to a feature branch Since this branch was just created from our local main branch it will include the changes that we committed to the main branch. This allows us to carry our work over to this new branch. However, if this branch already existed then this would not work. If we already had a branch called jm-15 , and we wanted to move commits from main to our feature branch, then what we could do instead is on the main branch run: To view the most recent commits. Make a note of the hash of each commit that you want to move over to the existing branch, e.g: NOTE: Type :q to exit the editor Then you can change back to your existing feature branch: and pull those commits into the feature branch using cherry-pick for each commit that you want to keep: To remove the commits from the main branch and get that back into a fresh state from the origin, you can just run: This will remove any staged commits and destroy your local work. If you switch between main and jm-15 now, you should see that main does not contain any changes and jm-15 does, which is what we should have done initially. Creating and merging a pull request Ok, we have our new work in its own branch now, which we were forced to do by the branch protection rules that we created. Now let’s see how we actually go about getting our changes merged into main . First, we will need to push our changes up to the remote repository: NOTE: —set-upstream origin jm-15 is only required if this is the first time you are pushing the branch to the remote repository (i.e. the branch does not exist in the remote repository yet) If you go to Github now you will see a notice like this: You can just click Compare & pull request here but that notice won’t be displayed forever. You can also create a pull request by going to the Pull requests tab and then clicking New pull request. You will want to set the base to main (or whatever your main branch is called) and the compare to jm-15 (or whatever the branch you are merging is called). You will then be able to review the changes: Once you are satisfied, click Create pull request. You will then be given the chance to add a comment, and then you can click Create pull request again to actually create the pull request. Then you will see a rather intimidating screen like this: The status checks aren’t actually of any concern to us here as we haven’t enabled status checks in our branch protection rules (we will likely cover that in another tutorial). What is blocking us at the moment though is the need for a review: To review a pull request you will need someone (who is not the person who created the pull request) to: Open the pull request and click on the Files changed tab Click Review changes Leave a comment, check Approve , and then Submit review Back on the main pull request page, click Merge pull request NOTE: You can not not approve your own pull requests, so if you are working on the repository by yourself you will need to bypass the review restrictions by just clicking Merge pull request without submitting a review. The Include administrators option under the branch protection rules must be disabled in order to allow this. And we are done! Summary We all make mistakes, and wherever possible we shouldn’t rely on people manually following processes and following the rules. If mistakes from developers end up negatively affecting our codebase or product, then we should see it as a failure of our processes not of that developer. If we can use tools to help enforce the software development process we want to create, and protect/guide our developers in the process, then we should absolutely do that. It creates a much less stressful work environment for all stakeholders if you know there are safeguards in place. Источник When using protected branches (1 peer review) auto fails #1491 Comments Describe the bug We have protected branches branches turned on to ensure To Reproduce Add «Require pull request reviews before merging» Expected behavior Auto should deploy, bypassing the branch protections. Screenshots Environment information: Additional context Settings: The text was updated successfully, but these errors were encountered: Another option is to use a PAT instead of the gh action’s token. We are using a PAT. We were using the wrong token 😅 I 🙏 it works lol This isn’t really an Auto issue but rather a thought-out limitation of Github Actions: Yes I agree that it isn’t autos issue, but given auto have a deep relationship with Github it should be considered. I like the automated merge PR. Seems like it’s something that an auto plugin could support? If protected branches is enabled then create a release PR rather than pushing to master. Additionally, it could utilize the API to use the associated admin permissions granted through the PAT to merge the release PR. If protected branches is enabled then create a release PR rather than pushing to master. Currently this would be a little more work than that. Each plugin is responsible for pushing the changlog/version commits. To make this pluggable we would need: to move that behavior into core make a new hook for pushing the release make a plugin that uses that hook to do what you described I kind of like what https://github.com/benjefferies/branch-protection-bot does. this would be easier to do via a plugin: Turn off branch protection during the afterVersion hook Turn on branch protection during the afterPublish hook Just gotta find the right octokit API It surely will work, but it seems precarious and potentially problematic for orgs that have strict controls around branch protection. I scanned through the plugins and I see what you mean. Instead of moving the changelog / version to core what if there were different types of plugins. For instance if the conventional-commit plugin was broken into two plugin types: conventional-commit-changelog and conventional-commit-version. If I want to use conventional-commit changelogs, but use github labels for my versioning I can. Possibly, a much larger conversation, but I’d be interested in assisting in developing a more robust solution which would satisfy various org requirements. It surely will work, but it seems precarious and potentially problematic for orgs that have strict controls around branch protection And if it the publish were to fail the branch protection rules would be lost 😢 The work to move the tag pushing into core looks like: Move all git push —tags calls from publish hooks to after this line Examples of git push —tags calls: Looking at this more it might be tricky finding all the places where we would push a commit to the baseBranch to switch to the PR flow you described. Create a new hook called something like push that’s a bail hook Set up the default behavior to just do the push Create a plugin (as a package or internally) that overrides the default behavior and makes the PR So I’m gonna close the PR I made to do this in a plugin as it seems to brittle. I’d be willing to accept a PR for this but it also seems like a pretty big lift. Although I had planned on moving the tag pushing into core at some point to facilitate #917 Possibly, a much larger conversation, but I’d be interested in assisting in developing a more robust solution which would satisfy various org requirements. feel free to discuss this here! I’ve made changes to my PR that will re-enable the Peer Reviews even when something in auto throws an error. So this should be a little less brittle now. So the only way this wouldn’t work now is if: you don’t have permission to change this setting you hit the «merge quickly» window perfectly (low chance and i’m pretty sure the first one would abort before any weirdness) As for the PR method you are describing. It goes pretty far out of the way of auto ‘s normal workflow. The biggest pain point I can imagine is that since you would be pushing tags to branches there would be a possibility of multiple PR merges creating branches with conflicting tags. We could write code that makes sure we only have 1 of those PRs up at a time but I feel like there would be some edge case weirdness to deal with. What’s weird is that this works fine for me on GitHub enterprise. On enterprise we use a dummy «bot» account with admin permissions to do this. Locally on my test project i’ve made a key with all permissons and it still doesn’t work at all. That is strange. We don’t use Enterprise at my org, but I have experienced the same issue on our (teams?) account despite being an Admin or using our dummy account which is also an admin. I need to look at how our Buildkite jobs do this. Maybe they found a trick that works. I’m going to formalize my thoughts and post about it tomorrow. Thanks for your attentiveness and support. All sources point to a token from an admin with the right permissions should fix this. I’m trying this on this repo to no avail. what’s weird is everything works fine locally using the same exact token. I can push directly to master but the same token doesn’t work in CI I’m in contact with someone who works at github and there might be a fix to this coming out at some point Источник
7. Why do we want to use pull requests? As I mentioned at the beginning, there is nothing stopping any contributor in our repository from just pulling down the main branch and pushing right back to it. This violates the task branching model we are trying to follow, and we just have to hope that people follow the rules. Even if people do make a good faith effort to follow the rules in general, there will almost certainly be times where these rules are violated. Although this will be our main motivation for enforcing that pull requests are used, using pull requests and reviews is also just a good idea from a collaboration and code review perspective. Enforcing pull requests Making a pull request required for merging into the main branch (or any branch) is quite easy with Github. Let’s do it now. Go to Settings > Branches Click Add rule on Branch protection rules Add main as the Branch name pattern Now you can set whatever rules you want. We are going to add the following rules: Once you have enabled the rules you need, you just need to click Create . NOTE: If you are the only person working on this repository you should not check the Include Administrators option. You can not review your own pull requests, so you will need the ability to bypass the review requirement. Unfortunately, this will also allow you to push directly to the main branch so it defeats the purpose of doing this in the first place. As I mentioned, I still think it is a good idea to set up and follow this process as if it were required, but just know that your admin privileges remove the protections we are putting in place. An example of the workflow with pull requests Let’s see what our workflow looks like now. One of our main goals here was to stop people from pushing changes directly to the main branch. Let’s see what happens if we accidentally worked on the main branch and tries to push it: git checkout main git commit -m «pushing straight to main» NOTE: If you have not set the Include Administrators option mentioned above the push to main will work. Perfect, our push was rejected. Realising our error we might now want to move our commits onto a new branch. First, we will create an issue for the branch we are creating: NOTE: Creating an issue isn’t actually enforced. Then we will create a new branch that references that issue (using the branch name format we discussed in the first tutorial in this series): BONUS TIP: Moving work committed onto the main branch to a feature branch Since this branch was just created from our local main branch it will include the changes that we committed to the main branch. This allows us to carry our work over to this new branch. However, if this branch already existed then this would not work. If we already had a branch called jm-15 , and we wanted to move commits from main to our feature branch, then what we could do instead is on the main branch run: To view the most recent commits. Make a note of the hash of each commit that you want to move over to the existing branch, e.g: NOTE: Type :q to exit the editor Then you can change back to your existing feature branch: and pull those commits into the feature branch using cherry-pick for each commit that you want to keep: To remove the commits from the main branch and get that back into a fresh state from the origin, you can just run: This will remove any staged commits and destroy your local work. If you switch between main and jm-15 now, you should see that main does not contain any changes and jm-15 does, which is what we should have done initially. Creating and merging a pull request Ok, we have our new work in its own branch now, which we were forced to do by the branch protection rules that we created. Now let’s see how we actually go about getting our changes merged into main . First, we will need to push our changes up to the remote repository: NOTE: —set-upstream origin jm-15 is only required if this is the first time you are pushing the branch to the remote repository (i.e. the branch does not exist in the remote repository yet) If you go to Github now you will see a notice like this: You can just click Compare & pull request here but that notice won’t be displayed forever. You can also create a pull request by going to the Pull requests tab and then clicking New pull request. You will want to set the base to main (or whatever your main branch is called) and the compare to jm-15 (or whatever the branch you are merging is called). You will then be able to review the changes: Once you are satisfied, click Create pull request. You will then be given the chance to add a comment, and then you can click Create pull request again to actually create the pull request. Then you will see a rather intimidating screen like this: The status checks aren’t actually of any concern to us here as we haven’t enabled status checks in our branch protection rules (we will likely cover that in another tutorial). What is blocking us at the moment though is the need for a review: To review a pull request you will need someone (who is not the person who created the pull request) to: Open the pull request and click on the Files changed tab Click Review changes Leave a comment, check Approve , and then Submit review Back on the main pull request page, click Merge pull request NOTE: You can not not approve your own pull requests, so if you are working on the repository by yourself you will need to bypass the review restrictions by just clicking Merge pull request without submitting a review. The Include administrators option under the branch protection rules must be disabled in order to allow this. And we are done! Summary We all make mistakes, and wherever possible we shouldn’t rely on people manually following processes and following the rules. If mistakes from developers end up negatively affecting our codebase or product, then we should see it as a failure of our processes not of that developer. If we can use tools to help enforce the software development process we want to create, and protect/guide our developers in the process, then we should absolutely do that. It creates a much less stressful work environment for all stakeholders if you know there are safeguards in place. Источник When using protected branches (1 peer review) auto fails #1491 Comments Describe the bug We have protected branches branches turned on to ensure To Reproduce Add «Require pull request reviews before merging» Expected behavior Auto should deploy, bypassing the branch protections. Screenshots Environment information: Additional context Settings: The text was updated successfully, but these errors were encountered: Another option is to use a PAT instead of the gh action’s token. We are using a PAT. We were using the wrong token 😅 I 🙏 it works lol This isn’t really an Auto issue but rather a thought-out limitation of Github Actions: Yes I agree that it isn’t autos issue, but given auto have a deep relationship with Github it should be considered. I like the automated merge PR. Seems like it’s something that an auto plugin could support? If protected branches is enabled then create a release PR rather than pushing to master. Additionally, it could utilize the API to use the associated admin permissions granted through the PAT to merge the release PR. If protected branches is enabled then create a release PR rather than pushing to master. Currently this would be a little more work than that. Each plugin is responsible for pushing the changlog/version commits. To make this pluggable we would need: to move that behavior into core make a new hook for pushing the release make a plugin that uses that hook to do what you described I kind of like what https://github.com/benjefferies/branch-protection-bot does. this would be easier to do via a plugin: Turn off branch protection during the afterVersion hook Turn on branch protection during the afterPublish hook Just gotta find the right octokit API It surely will work, but it seems precarious and potentially problematic for orgs that have strict controls around branch protection. I scanned through the plugins and I see what you mean. Instead of moving the changelog / version to core what if there were different types of plugins. For instance if the conventional-commit plugin was broken into two plugin types: conventional-commit-changelog and conventional-commit-version. If I want to use conventional-commit changelogs, but use github labels for my versioning I can. Possibly, a much larger conversation, but I’d be interested in assisting in developing a more robust solution which would satisfy various org requirements. It surely will work, but it seems precarious and potentially problematic for orgs that have strict controls around branch protection And if it the publish were to fail the branch protection rules would be lost 😢 The work to move the tag pushing into core looks like: Move all git push —tags calls from publish hooks to after this line Examples of git push —tags calls: Looking at this more it might be tricky finding all the places where we would push a commit to the baseBranch to switch to the PR flow you described. Create a new hook called something like push that’s a bail hook Set up the default behavior to just do the push Create a plugin (as a package or internally) that overrides the default behavior and makes the PR So I’m gonna close the PR I made to do this in a plugin as it seems to brittle. I’d be willing to accept a PR for this but it also seems like a pretty big lift. Although I had planned on moving the tag pushing into core at some point to facilitate #917 Possibly, a much larger conversation, but I’d be interested in assisting in developing a more robust solution which would satisfy various org requirements. feel free to discuss this here! I’ve made changes to my PR that will re-enable the Peer Reviews even when something in auto throws an error. So this should be a little less brittle now. So the only way this wouldn’t work now is if: you don’t have permission to change this setting you hit the «merge quickly» window perfectly (low chance and i’m pretty sure the first one would abort before any weirdness) As for the PR method you are describing. It goes pretty far out of the way of auto ‘s normal workflow. The biggest pain point I can imagine is that since you would be pushing tags to branches there would be a possibility of multiple PR merges creating branches with conflicting tags. We could write code that makes sure we only have 1 of those PRs up at a time but I feel like there would be some edge case weirdness to deal with. What’s weird is that this works fine for me on GitHub enterprise. On enterprise we use a dummy «bot» account with admin permissions to do this. Locally on my test project i’ve made a key with all permissons and it still doesn’t work at all. That is strange. We don’t use Enterprise at my org, but I have experienced the same issue on our (teams?) account despite being an Admin or using our dummy account which is also an admin. I need to look at how our Buildkite jobs do this. Maybe they found a trick that works. I’m going to formalize my thoughts and post about it tomorrow. Thanks for your attentiveness and support. All sources point to a token from an admin with the right permissions should fix this. I’m trying this on this repo to no avail. what’s weird is everything works fine locally using the same exact token. I can push directly to master but the same token doesn’t work in CI I’m in contact with someone who works at github and there might be a fix to this coming out at some point Источник
8. Enforcing pull requests Making a pull request required for merging into the main branch (or any branch) is quite easy with Github. Let’s do it now. Go to Settings > Branches Click Add rule on Branch protection rules Add main as the Branch name pattern Now you can set whatever rules you want. We are going to add the following rules: Once you have enabled the rules you need, you just need to click Create . NOTE: If you are the only person working on this repository you should not check the Include Administrators option. You can not review your own pull requests, so you will need the ability to bypass the review requirement. Unfortunately, this will also allow you to push directly to the main branch so it defeats the purpose of doing this in the first place. As I mentioned, I still think it is a good idea to set up and follow this process as if it were required, but just know that your admin privileges remove the protections we are putting in place. An example of the workflow with pull requests Let’s see what our workflow looks like now. One of our main goals here was to stop people from pushing changes directly to the main branch. Let’s see what happens if we accidentally worked on the main branch and tries to push it: git checkout main git commit -m «pushing straight to main» NOTE: If you have not set the Include Administrators option mentioned above the push to main will work. Perfect, our push was rejected. Realising our error we might now want to move our commits onto a new branch. First, we will create an issue for the branch we are creating: NOTE: Creating an issue isn’t actually enforced. Then we will create a new branch that references that issue (using the branch name format we discussed in the first tutorial in this series): BONUS TIP: Moving work committed onto the main branch to a feature branch Since this branch was just created from our local main branch it will include the changes that we committed to the main branch. This allows us to carry our work over to this new branch. However, if this branch already existed then this would not work. If we already had a branch called jm-15 , and we wanted to move commits from main to our feature branch, then what we could do instead is on the main branch run: To view the most recent commits. Make a note of the hash of each commit that you want to move over to the existing branch, e.g: NOTE: Type :q to exit the editor Then you can change back to your existing feature branch: and pull those commits into the feature branch using cherry-pick for each commit that you want to keep: To remove the commits from the main branch and get that back into a fresh state from the origin, you can just run: This will remove any staged commits and destroy your local work. If you switch between main and jm-15 now, you should see that main does not contain any changes and jm-15 does, which is what we should have done initially. Creating and merging a pull request Ok, we have our new work in its own branch now, which we were forced to do by the branch protection rules that we created. Now let’s see how we actually go about getting our changes merged into main . First, we will need to push our changes up to the remote repository: NOTE: —set-upstream origin jm-15 is only required if this is the first time you are pushing the branch to the remote repository (i.e. the branch does not exist in the remote repository yet) If you go to Github now you will see a notice like this: You can just click Compare & pull request here but that notice won’t be displayed forever. You can also create a pull request by going to the Pull requests tab and then clicking New pull request. You will want to set the base to main (or whatever your main branch is called) and the compare to jm-15 (or whatever the branch you are merging is called). You will then be able to review the changes: Once you are satisfied, click Create pull request. You will then be given the chance to add a comment, and then you can click Create pull request again to actually create the pull request. Then you will see a rather intimidating screen like this: The status checks aren’t actually of any concern to us here as we haven’t enabled status checks in our branch protection rules (we will likely cover that in another tutorial). What is blocking us at the moment though is the need for a review: To review a pull request you will need someone (who is not the person who created the pull request) to: Open the pull request and click on the Files changed tab Click Review changes Leave a comment, check Approve , and then Submit review Back on the main pull request page, click Merge pull request NOTE: You can not not approve your own pull requests, so if you are working on the repository by yourself you will need to bypass the review restrictions by just clicking Merge pull request without submitting a review. The Include administrators option under the branch protection rules must be disabled in order to allow this. And we are done! Summary We all make mistakes, and wherever possible we shouldn’t rely on people manually following processes and following the rules. If mistakes from developers end up negatively affecting our codebase or product, then we should see it as a failure of our processes not of that developer. If we can use tools to help enforce the software development process we want to create, and protect/guide our developers in the process, then we should absolutely do that. It creates a much less stressful work environment for all stakeholders if you know there are safeguards in place. Источник When using protected branches (1 peer review) auto fails #1491 Comments Describe the bug We have protected branches branches turned on to ensure To Reproduce Add «Require pull request reviews before merging» Expected behavior Auto should deploy, bypassing the branch protections. Screenshots Environment information: Additional context Settings: The text was updated successfully, but these errors were encountered: Another option is to use a PAT instead of the gh action’s token. We are using a PAT. We were using the wrong token 😅 I 🙏 it works lol This isn’t really an Auto issue but rather a thought-out limitation of Github Actions: Yes I agree that it isn’t autos issue, but given auto have a deep relationship with Github it should be considered. I like the automated merge PR. Seems like it’s something that an auto plugin could support? If protected branches is enabled then create a release PR rather than pushing to master. Additionally, it could utilize the API to use the associated admin permissions granted through the PAT to merge the release PR. If protected branches is enabled then create a release PR rather than pushing to master. Currently this would be a little more work than that. Each plugin is responsible for pushing the changlog/version commits. To make this pluggable we would need: to move that behavior into core make a new hook for pushing the release make a plugin that uses that hook to do what you described I kind of like what https://github.com/benjefferies/branch-protection-bot does. this would be easier to do via a plugin: Turn off branch protection during the afterVersion hook Turn on branch protection during the afterPublish hook Just gotta find the right octokit API It surely will work, but it seems precarious and potentially problematic for orgs that have strict controls around branch protection. I scanned through the plugins and I see what you mean. Instead of moving the changelog / version to core what if there were different types of plugins. For instance if the conventional-commit plugin was broken into two plugin types: conventional-commit-changelog and conventional-commit-version. If I want to use conventional-commit changelogs, but use github labels for my versioning I can. Possibly, a much larger conversation, but I’d be interested in assisting in developing a more robust solution which would satisfy various org requirements. It surely will work, but it seems precarious and potentially problematic for orgs that have strict controls around branch protection And if it the publish were to fail the branch protection rules would be lost 😢 The work to move the tag pushing into core looks like: Move all git push —tags calls from publish hooks to after this line Examples of git push —tags calls: Looking at this more it might be tricky finding all the places where we would push a commit to the baseBranch to switch to the PR flow you described. Create a new hook called something like push that’s a bail hook Set up the default behavior to just do the push Create a plugin (as a package or internally) that overrides the default behavior and makes the PR So I’m gonna close the PR I made to do this in a plugin as it seems to brittle. I’d be willing to accept a PR for this but it also seems like a pretty big lift. Although I had planned on moving the tag pushing into core at some point to facilitate #917 Possibly, a much larger conversation, but I’d be interested in assisting in developing a more robust solution which would satisfy various org requirements. feel free to discuss this here! I’ve made changes to my PR that will re-enable the Peer Reviews even when something in auto throws an error. So this should be a little less brittle now. So the only way this wouldn’t work now is if: you don’t have permission to change this setting you hit the «merge quickly» window perfectly (low chance and i’m pretty sure the first one would abort before any weirdness) As for the PR method you are describing. It goes pretty far out of the way of auto ‘s normal workflow. The biggest pain point I can imagine is that since you would be pushing tags to branches there would be a possibility of multiple PR merges creating branches with conflicting tags. We could write code that makes sure we only have 1 of those PRs up at a time but I feel like there would be some edge case weirdness to deal with. What’s weird is that this works fine for me on GitHub enterprise. On enterprise we use a dummy «bot» account with admin permissions to do this. Locally on my test project i’ve made a key with all permissons and it still doesn’t work at all. That is strange. We don’t use Enterprise at my org, but I have experienced the same issue on our (teams?) account despite being an Admin or using our dummy account which is also an admin. I need to look at how our Buildkite jobs do this. Maybe they found a trick that works. I’m going to formalize my thoughts and post about it tomorrow. Thanks for your attentiveness and support. All sources point to a token from an admin with the right permissions should fix this. I’m trying this on this repo to no avail. what’s weird is everything works fine locally using the same exact token. I can push directly to master but the same token doesn’t work in CI I’m in contact with someone who works at github and there might be a fix to this coming out at some point Источник
9. An example of the workflow with pull requests Let’s see what our workflow looks like now. One of our main goals here was to stop people from pushing changes directly to the main branch. Let’s see what happens if we accidentally worked on the main branch and tries to push it: git checkout main git commit -m «pushing straight to main» NOTE: If you have not set the Include Administrators option mentioned above the push to main will work. Perfect, our push was rejected. Realising our error we might now want to move our commits onto a new branch. First, we will create an issue for the branch we are creating: NOTE: Creating an issue isn’t actually enforced. Then we will create a new branch that references that issue (using the branch name format we discussed in the first tutorial in this series): BONUS TIP: Moving work committed onto the main branch to a feature branch Since this branch was just created from our local main branch it will include the changes that we committed to the main branch. This allows us to carry our work over to this new branch. However, if this branch already existed then this would not work. If we already had a branch called jm-15 , and we wanted to move commits from main to our feature branch, then what we could do instead is on the main branch run: To view the most recent commits. Make a note of the hash of each commit that you want to move over to the existing branch, e.g: NOTE: Type :q to exit the editor Then you can change back to your existing feature branch: and pull those commits into the feature branch using cherry-pick for each commit that you want to keep: To remove the commits from the main branch and get that back into a fresh state from the origin, you can just run: This will remove any staged commits and destroy your local work. If you switch between main and jm-15 now, you should see that main does not contain any changes and jm-15 does, which is what we should have done initially. Creating and merging a pull request Ok, we have our new work in its own branch now, which we were forced to do by the branch protection rules that we created. Now let’s see how we actually go about getting our changes merged into main . First, we will need to push our changes up to the remote repository: NOTE: —set-upstream origin jm-15 is only required if this is the first time you are pushing the branch to the remote repository (i.e. the branch does not exist in the remote repository yet) If you go to Github now you will see a notice like this: You can just click Compare & pull request here but that notice won’t be displayed forever. You can also create a pull request by going to the Pull requests tab and then clicking New pull request. You will want to set the base to main (or whatever your main branch is called) and the compare to jm-15 (or whatever the branch you are merging is called). You will then be able to review the changes: Once you are satisfied, click Create pull request. You will then be given the chance to add a comment, and then you can click Create pull request again to actually create the pull request. Then you will see a rather intimidating screen like this: The status checks aren’t actually of any concern to us here as we haven’t enabled status checks in our branch protection rules (we will likely cover that in another tutorial). What is blocking us at the moment though is the need for a review: To review a pull request you will need someone (who is not the person who created the pull request) to: Open the pull request and click on the Files changed tab Click Review changes Leave a comment, check Approve , and then Submit review Back on the main pull request page, click Merge pull request NOTE: You can not not approve your own pull requests, so if you are working on the repository by yourself you will need to bypass the review restrictions by just clicking Merge pull request without submitting a review. The Include administrators option under the branch protection rules must be disabled in order to allow this. And we are done! Summary We all make mistakes, and wherever possible we shouldn’t rely on people manually following processes and following the rules. If mistakes from developers end up negatively affecting our codebase or product, then we should see it as a failure of our processes not of that developer. If we can use tools to help enforce the software development process we want to create, and protect/guide our developers in the process, then we should absolutely do that. It creates a much less stressful work environment for all stakeholders if you know there are safeguards in place. Источник When using protected branches (1 peer review) auto fails #1491 Comments Describe the bug We have protected branches branches turned on to ensure To Reproduce Add «Require pull request reviews before merging» Expected behavior Auto should deploy, bypassing the branch protections. Screenshots Environment information: Additional context Settings: The text was updated successfully, but these errors were encountered: Another option is to use a PAT instead of the gh action’s token. We are using a PAT. We were using the wrong token 😅 I 🙏 it works lol This isn’t really an Auto issue but rather a thought-out limitation of Github Actions: Yes I agree that it isn’t autos issue, but given auto have a deep relationship with Github it should be considered. I like the automated merge PR. Seems like it’s something that an auto plugin could support? If protected branches is enabled then create a release PR rather than pushing to master. Additionally, it could utilize the API to use the associated admin permissions granted through the PAT to merge the release PR. If protected branches is enabled then create a release PR rather than pushing to master. Currently this would be a little more work than that. Each plugin is responsible for pushing the changlog/version commits. To make this pluggable we would need: to move that behavior into core make a new hook for pushing the release make a plugin that uses that hook to do what you described I kind of like what https://github.com/benjefferies/branch-protection-bot does. this would be easier to do via a plugin: Turn off branch protection during the afterVersion hook Turn on branch protection during the afterPublish hook Just gotta find the right octokit API It surely will work, but it seems precarious and potentially problematic for orgs that have strict controls around branch protection. I scanned through the plugins and I see what you mean. Instead of moving the changelog / version to core what if there were different types of plugins. For instance if the conventional-commit plugin was broken into two plugin types: conventional-commit-changelog and conventional-commit-version. If I want to use conventional-commit changelogs, but use github labels for my versioning I can. Possibly, a much larger conversation, but I’d be interested in assisting in developing a more robust solution which would satisfy various org requirements. It surely will work, but it seems precarious and potentially problematic for orgs that have strict controls around branch protection And if it the publish were to fail the branch protection rules would be lost 😢 The work to move the tag pushing into core looks like: Move all git push —tags calls from publish hooks to after this line Examples of git push —tags calls: Looking at this more it might be tricky finding all the places where we would push a commit to the baseBranch to switch to the PR flow you described. Create a new hook called something like push that’s a bail hook Set up the default behavior to just do the push Create a plugin (as a package or internally) that overrides the default behavior and makes the PR So I’m gonna close the PR I made to do this in a plugin as it seems to brittle. I’d be willing to accept a PR for this but it also seems like a pretty big lift. Although I had planned on moving the tag pushing into core at some point to facilitate #917 Possibly, a much larger conversation, but I’d be interested in assisting in developing a more robust solution which would satisfy various org requirements. feel free to discuss this here! I’ve made changes to my PR that will re-enable the Peer Reviews even when something in auto throws an error. So this should be a little less brittle now. So the only way this wouldn’t work now is if: you don’t have permission to change this setting you hit the «merge quickly» window perfectly (low chance and i’m pretty sure the first one would abort before any weirdness) As for the PR method you are describing. It goes pretty far out of the way of auto ‘s normal workflow. The biggest pain point I can imagine is that since you would be pushing tags to branches there would be a possibility of multiple PR merges creating branches with conflicting tags. We could write code that makes sure we only have 1 of those PRs up at a time but I feel like there would be some edge case weirdness to deal with. What’s weird is that this works fine for me on GitHub enterprise. On enterprise we use a dummy «bot» account with admin permissions to do this. Locally on my test project i’ve made a key with all permissons and it still doesn’t work at all. That is strange. We don’t use Enterprise at my org, but I have experienced the same issue on our (teams?) account despite being an Admin or using our dummy account which is also an admin. I need to look at how our Buildkite jobs do this. Maybe they found a trick that works. I’m going to formalize my thoughts and post about it tomorrow. Thanks for your attentiveness and support. All sources point to a token from an admin with the right permissions should fix this. I’m trying this on this repo to no avail. what’s weird is everything works fine locally using the same exact token. I can push directly to master but the same token doesn’t work in CI I’m in contact with someone who works at github and there might be a fix to this coming out at some point Источник
10. BONUS TIP: Moving work committed onto the main branch to a feature branch Since this branch was just created from our local main branch it will include the changes that we committed to the main branch. This allows us to carry our work over to this new branch. However, if this branch already existed then this would not work. If we already had a branch called jm-15 , and we wanted to move commits from main to our feature branch, then what we could do instead is on the main branch run: To view the most recent commits. Make a note of the hash of each commit that you want to move over to the existing branch, e.g: NOTE: Type :q to exit the editor Then you can change back to your existing feature branch: and pull those commits into the feature branch using cherry-pick for each commit that you want to keep: To remove the commits from the main branch and get that back into a fresh state from the origin, you can just run: This will remove any staged commits and destroy your local work. If you switch between main and jm-15 now, you should see that main does not contain any changes and jm-15 does, which is what we should have done initially. Creating and merging a pull request Ok, we have our new work in its own branch now, which we were forced to do by the branch protection rules that we created. Now let’s see how we actually go about getting our changes merged into main . First, we will need to push our changes up to the remote repository: NOTE: —set-upstream origin jm-15 is only required if this is the first time you are pushing the branch to the remote repository (i.e. the branch does not exist in the remote repository yet) If you go to Github now you will see a notice like this: You can just click Compare & pull request here but that notice won’t be displayed forever. You can also create a pull request by going to the Pull requests tab and then clicking New pull request. You will want to set the base to main (or whatever your main branch is called) and the compare to jm-15 (or whatever the branch you are merging is called). You will then be able to review the changes: Once you are satisfied, click Create pull request. You will then be given the chance to add a comment, and then you can click Create pull request again to actually create the pull request. Then you will see a rather intimidating screen like this: The status checks aren’t actually of any concern to us here as we haven’t enabled status checks in our branch protection rules (we will likely cover that in another tutorial). What is blocking us at the moment though is the need for a review: To review a pull request you will need someone (who is not the person who created the pull request) to: Open the pull request and click on the Files changed tab Click Review changes Leave a comment, check Approve , and then Submit review Back on the main pull request page, click Merge pull request NOTE: You can not not approve your own pull requests, so if you are working on the repository by yourself you will need to bypass the review restrictions by just clicking Merge pull request without submitting a review. The Include administrators option under the branch protection rules must be disabled in order to allow this. And we are done! Summary We all make mistakes, and wherever possible we shouldn’t rely on people manually following processes and following the rules. If mistakes from developers end up negatively affecting our codebase or product, then we should see it as a failure of our processes not of that developer. If we can use tools to help enforce the software development process we want to create, and protect/guide our developers in the process, then we should absolutely do that. It creates a much less stressful work environment for all stakeholders if you know there are safeguards in place. Источник When using protected branches (1 peer review) auto fails #1491 Comments Describe the bug We have protected branches branches turned on to ensure To Reproduce Add «Require pull request reviews before merging» Expected behavior Auto should deploy, bypassing the branch protections. Screenshots Environment information: Additional context Settings: The text was updated successfully, but these errors were encountered: Another option is to use a PAT instead of the gh action’s token. We are using a PAT. We were using the wrong token 😅 I 🙏 it works lol This isn’t really an Auto issue but rather a thought-out limitation of Github Actions: Yes I agree that it isn’t autos issue, but given auto have a deep relationship with Github it should be considered. I like the automated merge PR. Seems like it’s something that an auto plugin could support? If protected branches is enabled then create a release PR rather than pushing to master. Additionally, it could utilize the API to use the associated admin permissions granted through the PAT to merge the release PR. If protected branches is enabled then create a release PR rather than pushing to master. Currently this would be a little more work than that. Each plugin is responsible for pushing the changlog/version commits. To make this pluggable we would need: to move that behavior into core make a new hook for pushing the release make a plugin that uses that hook to do what you described I kind of like what https://github.com/benjefferies/branch-protection-bot does. this would be easier to do via a plugin: Turn off branch protection during the afterVersion hook Turn on branch protection during the afterPublish hook Just gotta find the right octokit API It surely will work, but it seems precarious and potentially problematic for orgs that have strict controls around branch protection. I scanned through the plugins and I see what you mean. Instead of moving the changelog / version to core what if there were different types of plugins. For instance if the conventional-commit plugin was broken into two plugin types: conventional-commit-changelog and conventional-commit-version. If I want to use conventional-commit changelogs, but use github labels for my versioning I can. Possibly, a much larger conversation, but I’d be interested in assisting in developing a more robust solution which would satisfy various org requirements. It surely will work, but it seems precarious and potentially problematic for orgs that have strict controls around branch protection And if it the publish were to fail the branch protection rules would be lost 😢 The work to move the tag pushing into core looks like: Move all git push —tags calls from publish hooks to after this line Examples of git push —tags calls: Looking at this more it might be tricky finding all the places where we would push a commit to the baseBranch to switch to the PR flow you described. Create a new hook called something like push that’s a bail hook Set up the default behavior to just do the push Create a plugin (as a package or internally) that overrides the default behavior and makes the PR So I’m gonna close the PR I made to do this in a plugin as it seems to brittle. I’d be willing to accept a PR for this but it also seems like a pretty big lift. Although I had planned on moving the tag pushing into core at some point to facilitate #917 Possibly, a much larger conversation, but I’d be interested in assisting in developing a more robust solution which would satisfy various org requirements. feel free to discuss this here! I’ve made changes to my PR that will re-enable the Peer Reviews even when something in auto throws an error. So this should be a little less brittle now. So the only way this wouldn’t work now is if: you don’t have permission to change this setting you hit the «merge quickly» window perfectly (low chance and i’m pretty sure the first one would abort before any weirdness) As for the PR method you are describing. It goes pretty far out of the way of auto ‘s normal workflow. The biggest pain point I can imagine is that since you would be pushing tags to branches there would be a possibility of multiple PR merges creating branches with conflicting tags. We could write code that makes sure we only have 1 of those PRs up at a time but I feel like there would be some edge case weirdness to deal with. What’s weird is that this works fine for me on GitHub enterprise. On enterprise we use a dummy «bot» account with admin permissions to do this. Locally on my test project i’ve made a key with all permissons and it still doesn’t work at all. That is strange. We don’t use Enterprise at my org, but I have experienced the same issue on our (teams?) account despite being an Admin or using our dummy account which is also an admin. I need to look at how our Buildkite jobs do this. Maybe they found a trick that works. I’m going to formalize my thoughts and post about it tomorrow. Thanks for your attentiveness and support. All sources point to a token from an admin with the right permissions should fix this. I’m trying this on this repo to no avail. what’s weird is everything works fine locally using the same exact token. I can push directly to master but the same token doesn’t work in CI I’m in contact with someone who works at github and there might be a fix to this coming out at some point Источник
11. Creating and merging a pull request Ok, we have our new work in its own branch now, which we were forced to do by the branch protection rules that we created. Now let’s see how we actually go about getting our changes merged into main . First, we will need to push our changes up to the remote repository: NOTE: —set-upstream origin jm-15 is only required if this is the first time you are pushing the branch to the remote repository (i.e. the branch does not exist in the remote repository yet) If you go to Github now you will see a notice like this: You can just click Compare & pull request here but that notice won’t be displayed forever. You can also create a pull request by going to the Pull requests tab and then clicking New pull request. You will want to set the base to main (or whatever your main branch is called) and the compare to jm-15 (or whatever the branch you are merging is called). You will then be able to review the changes: Once you are satisfied, click Create pull request. You will then be given the chance to add a comment, and then you can click Create pull request again to actually create the pull request. Then you will see a rather intimidating screen like this: The status checks aren’t actually of any concern to us here as we haven’t enabled status checks in our branch protection rules (we will likely cover that in another tutorial). What is blocking us at the moment though is the need for a review: To review a pull request you will need someone (who is not the person who created the pull request) to: Open the pull request and click on the Files changed tab Click Review changes Leave a comment, check Approve , and then Submit review Back on the main pull request page, click Merge pull request NOTE: You can not not approve your own pull requests, so if you are working on the repository by yourself you will need to bypass the review restrictions by just clicking Merge pull request without submitting a review. The Include administrators option under the branch protection rules must be disabled in order to allow this. And we are done! Summary We all make mistakes, and wherever possible we shouldn’t rely on people manually following processes and following the rules. If mistakes from developers end up negatively affecting our codebase or product, then we should see it as a failure of our processes not of that developer. If we can use tools to help enforce the software development process we want to create, and protect/guide our developers in the process, then we should absolutely do that. It creates a much less stressful work environment for all stakeholders if you know there are safeguards in place. Источник When using protected branches (1 peer review) auto fails #1491 Comments Describe the bug We have protected branches branches turned on to ensure To Reproduce Add «Require pull request reviews before merging» Expected behavior Auto should deploy, bypassing the branch protections. Screenshots Environment information: Additional context Settings: The text was updated successfully, but these errors were encountered: Another option is to use a PAT instead of the gh action’s token. We are using a PAT. We were using the wrong token 😅 I 🙏 it works lol This isn’t really an Auto issue but rather a thought-out limitation of Github Actions: Yes I agree that it isn’t autos issue, but given auto have a deep relationship with Github it should be considered. I like the automated merge PR. Seems like it’s something that an auto plugin could support? If protected branches is enabled then create a release PR rather than pushing to master. Additionally, it could utilize the API to use the associated admin permissions granted through the PAT to merge the release PR. If protected branches is enabled then create a release PR rather than pushing to master. Currently this would be a little more work than that. Each plugin is responsible for pushing the changlog/version commits. To make this pluggable we would need: to move that behavior into core make a new hook for pushing the release make a plugin that uses that hook to do what you described I kind of like what https://github.com/benjefferies/branch-protection-bot does. this would be easier to do via a plugin: Turn off branch protection during the afterVersion hook Turn on branch protection during the afterPublish hook Just gotta find the right octokit API It surely will work, but it seems precarious and potentially problematic for orgs that have strict controls around branch protection. I scanned through the plugins and I see what you mean. Instead of moving the changelog / version to core what if there were different types of plugins. For instance if the conventional-commit plugin was broken into two plugin types: conventional-commit-changelog and conventional-commit-version. If I want to use conventional-commit changelogs, but use github labels for my versioning I can. Possibly, a much larger conversation, but I’d be interested in assisting in developing a more robust solution which would satisfy various org requirements. It surely will work, but it seems precarious and potentially problematic for orgs that have strict controls around branch protection And if it the publish were to fail the branch protection rules would be lost 😢 The work to move the tag pushing into core looks like: Move all git push —tags calls from publish hooks to after this line Examples of git push —tags calls: Looking at this more it might be tricky finding all the places where we would push a commit to the baseBranch to switch to the PR flow you described. Create a new hook called something like push that’s a bail hook Set up the default behavior to just do the push Create a plugin (as a package or internally) that overrides the default behavior and makes the PR So I’m gonna close the PR I made to do this in a plugin as it seems to brittle. I’d be willing to accept a PR for this but it also seems like a pretty big lift. Although I had planned on moving the tag pushing into core at some point to facilitate #917 Possibly, a much larger conversation, but I’d be interested in assisting in developing a more robust solution which would satisfy various org requirements. feel free to discuss this here! I’ve made changes to my PR that will re-enable the Peer Reviews even when something in auto throws an error. So this should be a little less brittle now. So the only way this wouldn’t work now is if: you don’t have permission to change this setting you hit the «merge quickly» window perfectly (low chance and i’m pretty sure the first one would abort before any weirdness) As for the PR method you are describing. It goes pretty far out of the way of auto ‘s normal workflow. The biggest pain point I can imagine is that since you would be pushing tags to branches there would be a possibility of multiple PR merges creating branches with conflicting tags. We could write code that makes sure we only have 1 of those PRs up at a time but I feel like there would be some edge case weirdness to deal with. What’s weird is that this works fine for me on GitHub enterprise. On enterprise we use a dummy «bot» account with admin permissions to do this. Locally on my test project i’ve made a key with all permissons and it still doesn’t work at all. That is strange. We don’t use Enterprise at my org, but I have experienced the same issue on our (teams?) account despite being an Admin or using our dummy account which is also an admin. I need to look at how our Buildkite jobs do this. Maybe they found a trick that works. I’m going to formalize my thoughts and post about it tomorrow. Thanks for your attentiveness and support. All sources point to a token from an admin with the right permissions should fix this. I’m trying this on this repo to no avail. what’s weird is everything works fine locally using the same exact token. I can push directly to master but the same token doesn’t work in CI I’m in contact with someone who works at github and there might be a fix to this coming out at some point Источник
12. Summary We all make mistakes, and wherever possible we shouldn’t rely on people manually following processes and following the rules. If mistakes from developers end up negatively affecting our codebase or product, then we should see it as a failure of our processes not of that developer. If we can use tools to help enforce the software development process we want to create, and protect/guide our developers in the process, then we should absolutely do that. It creates a much less stressful work environment for all stakeholders if you know there are safeguards in place. Источник When using protected branches (1 peer review) auto fails #1491 Comments Describe the bug We have protected branches branches turned on to ensure To Reproduce Add «Require pull request reviews before merging» Expected behavior Auto should deploy, bypassing the branch protections. Screenshots Environment information: Additional context Settings: The text was updated successfully, but these errors were encountered: Another option is to use a PAT instead of the gh action’s token. We are using a PAT. We were using the wrong token 😅 I 🙏 it works lol This isn’t really an Auto issue but rather a thought-out limitation of Github Actions: Yes I agree that it isn’t autos issue, but given auto have a deep relationship with Github it should be considered. I like the automated merge PR. Seems like it’s something that an auto plugin could support? If protected branches is enabled then create a release PR rather than pushing to master. Additionally, it could utilize the API to use the associated admin permissions granted through the PAT to merge the release PR. If protected branches is enabled then create a release PR rather than pushing to master. Currently this would be a little more work than that. Each plugin is responsible for pushing the changlog/version commits. To make this pluggable we would need: to move that behavior into core make a new hook for pushing the release make a plugin that uses that hook to do what you described I kind of like what https://github.com/benjefferies/branch-protection-bot does. this would be easier to do via a plugin: Turn off branch protection during the afterVersion hook Turn on branch protection during the afterPublish hook Just gotta find the right octokit API It surely will work, but it seems precarious and potentially problematic for orgs that have strict controls around branch protection. I scanned through the plugins and I see what you mean. Instead of moving the changelog / version to core what if there were different types of plugins. For instance if the conventional-commit plugin was broken into two plugin types: conventional-commit-changelog and conventional-commit-version. If I want to use conventional-commit changelogs, but use github labels for my versioning I can. Possibly, a much larger conversation, but I’d be interested in assisting in developing a more robust solution which would satisfy various org requirements. It surely will work, but it seems precarious and potentially problematic for orgs that have strict controls around branch protection And if it the publish were to fail the branch protection rules would be lost 😢 The work to move the tag pushing into core looks like: Move all git push —tags calls from publish hooks to after this line Examples of git push —tags calls: Looking at this more it might be tricky finding all the places where we would push a commit to the baseBranch to switch to the PR flow you described. Create a new hook called something like push that’s a bail hook Set up the default behavior to just do the push Create a plugin (as a package or internally) that overrides the default behavior and makes the PR So I’m gonna close the PR I made to do this in a plugin as it seems to brittle. I’d be willing to accept a PR for this but it also seems like a pretty big lift. Although I had planned on moving the tag pushing into core at some point to facilitate #917 Possibly, a much larger conversation, but I’d be interested in assisting in developing a more robust solution which would satisfy various org requirements. feel free to discuss this here! I’ve made changes to my PR that will re-enable the Peer Reviews even when something in auto throws an error. So this should be a little less brittle now. So the only way this wouldn’t work now is if: you don’t have permission to change this setting you hit the «merge quickly» window perfectly (low chance and i’m pretty sure the first one would abort before any weirdness) As for the PR method you are describing. It goes pretty far out of the way of auto ‘s normal workflow. The biggest pain point I can imagine is that since you would be pushing tags to branches there would be a possibility of multiple PR merges creating branches with conflicting tags. We could write code that makes sure we only have 1 of those PRs up at a time but I feel like there would be some edge case weirdness to deal with. What’s weird is that this works fine for me on GitHub enterprise. On enterprise we use a dummy «bot» account with admin permissions to do this. Locally on my test project i’ve made a key with all permissons and it still doesn’t work at all. That is strange. We don’t use Enterprise at my org, but I have experienced the same issue on our (teams?) account despite being an Admin or using our dummy account which is also an admin. I need to look at how our Buildkite jobs do this. Maybe they found a trick that works. I’m going to formalize my thoughts and post about it tomorrow. Thanks for your attentiveness and support. All sources point to a token from an admin with the right permissions should fix this. I’m trying this on this repo to no avail. what’s weird is everything works fine locally using the same exact token. I can push directly to master but the same token doesn’t work in CI I’m in contact with someone who works at github and there might be a fix to this coming out at some point Источник
13. When using protected branches (1 peer review) auto fails #1491
14. Comments