I am aware of similar questions (How to protect "master" branch in GitHub? and How can we enforce mandatory reviews in GitHub but still allow Maven release builds from CI?) and of GitHub's "protected branches" feature. Sadly, so far, I have been unable to come up with a solution that fulfills all our requirements:
only administrators and automated process accounts (like Maven release on Jenkins) can push directly to master
everybody else must open a pull request (which requires an approval)
everybody can merge approved pull requests
We are a small organization on a GitHub "Team" plan, and we're happy to switch plans, if necessary. However, I'd like first to make sure that whatever other plan we choose would actually support all these requirements.
Related
I came across an issue with working GitHub actions,
I have built multiple central workflows for the ci-cd process and called this workflow in application repositories and building apps but some of the developers writing their own workflows to build applications and not following certain standards, so to make them use only central workflows I need to restrict any push to ".github/workflows" and allow only specified people to push to ".github/workflows"
since this is github-specific I'll give a github-specific answer:
set up CODEOWNERS for those files
.github/ #your-team
enable branch protection for the branches you want
make sure to check Require a pull request before merging
then check Require review from Code Owners
Recently I removed the writing rights of a former collaborator who left our github project.
Then I noticed that in the commits page there was no more report for the continuous integration tests with AppVeyer( by clicking on the red cross or the green check).
I gave again the write permission to this former collaborator and the report for AppVeyer became visible again.
So I looked more carefully at the features related to AppVeyor and this former collaborator. I saw that:
in https://ci.appveyor.com/team at Account > Team > GitHub teams, I have not yet granted access to any GitHub teams and by clicking on CONFIGURE TEAMS I see that AppVeyor is authorized to act on behalf of this_former_collaborator GitHub account with admin:repo_hook, read:org, repo:status scope.
in https://github.com, for our organization, by editing, in Seetings > Third-party access, the AppVeyor CI application, I see "approval requested by this_former_collaborator".
What can I do to remove the write rights to our Github project from this former contributor while keeping the results of the ongoing AppVeyor CI tests on the project commits page (and don't lose the history of the tests)?
Thanks to the fast and efficient help of AppVeyor's support team I was able to fixe this problem by authorising AppVeyor as GitHub App. Everything works fine now ...
For separation of duty purposes, my company has a policy that says developers involved in a change cannot be involved in the push of that code to staging or production, so we have a release team that reviews pull requests to those branches and pushes to the relevant environment.
The team leads want to be able to define policies for the dev and test branches because those branches have their own dedicated environments.
Our Azure admins are still learning Azure, so if someone can point to documentation that either explicitly states it is not possible to allow this, or documentation that describes how to set this up.
Edit: To clarify (hopefully), I'll put it in outline form.
Developers can create any branch and push and merge to and from it however they wish. Developers cannot manage policies on any branch.
Team leads for that team can define policies on specific branches (dev and test branches) but cannot on other branches (stg and prod branches).
Release Team can define policies on any branch, but specifically will manage stg and prod branches.
The first and last conditions are working. I can't figure out how to tell the azure admins to give the team leads permissions to manage policies only on specific branches.
Go to Project Settings -- Repositories, select the branch and set the Edit policy permission for the Team leads:
You would do this using a branch policy.
Developers would work on and push changes to a feature branch. When the code is ready they would create a pull request into the next branch in your pipeline.
It can be set up so that only your release team can approve the pull requests.
https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies-overview?view=azure-devops
looking for workflow solution. We need something like ad-hoc sharing workflow https://docs.bit.dev/docs/workflows/projects with one addition - before the component publishing could happen only after the code review. let me try to describe the short scenario:
there is a repo with the shared components
there are several consumer projects. each one sits in its own repo
there is no dedicated team to maintain the repo with the shared components
the developer of consumer project imports a share component and make changes
the developer wants to create a pull request for a component changes
So far I see only one solution - the developer manually applies changes he made locally to a shared library repo and manually creates a pull request. Kind of boring. Does the bit.dev provide an automated solution for such case?
While a PR-like feature is still not available in Bit, you can use Git's PR workflow to set up a code review process for components with some automation.
Note this flow can work regardless of the specific workflow your team implements. In this answer, I'll focus on the ad-hock flow, as your team uses.
You'll first need to set up automation on your projects, that when there's a change in component's code, your CI will bit tag && bit export the modified components. This should happen only when a PR is approved and merged to master branch (in Git).
Then using the Git integration feature set up your projects to receive PRs on new versions for components.
With these two setups, this will be the workflow your team can utilize:
Import component to any project and modify.
Submit PR to the project.
Have a peer do a code review.
When change is merged, run bit tag && bit export --eject during CI
Commit and push back changes to package.json to the repo (with a skip-ci flag, per your automation infrastructure).
All projects that use that component get a PR from Bit with the newly available version.
I will update this answer whenever a new feature in Bit improves on this workflow.
as Itay says, you can use the GitHub integration on bit.dev.
But if you want, I create demos projects that show how to use GitHub or Azure CI to integrate the project with Bit, and export new components when code our pushed to master, and also run Bit script on PRs.
https://github.com/teambit/bit-with-github-actions
https://github.com/teambit/bit-with-azure-devops
I hope it will help you.
Is it possible to merge pull request automaticaly to master branch on github after success of travis test webhook?
You can use Mergify to do this.
It allows to configure rules and define criteria for your pull request to be automatically merged. In your case, setting something like "Travis check is OK and one reviewer approved the PR" would allow the PR to be automatically merged.
(Disclosure: I'm part of the Mergify team.)
You can most probably add an after_success action to your .travis.yml that would merge the PR using GitHub API. I do not know of any ready to use script for this, but there is no reason for it to be hard. Special care needed for authentication ...
GitHub recently shipped this auto-merge feature in beta. To use this, you can enable it in the repo settings. Just keep in mind you will need to add branch protection rules as well.
See the documentation for more info.
https://docs.github.com/en/free-pro-team#latest/github/collaborating-with-issues-and-pull-requests/automatically-merging-a-pull-request
I work on a project that requires pull requests to be up to date with the target branch, and also to have passed all the checks before merging.
This means we can often be waiting for checks to finish, only to find a new commit has been made to the target branch, which requires the pull request to be synchronised and the checks to run all over again. I wanted a simple app to merge the PR automatically once the checks are successful, so I created one.
Mergery is:
Free, including for private repositories.
Fast. It's event-driven, it doesn't run on a schedule.
Simple. No configuration required. Just label your PRs with automerge.