We're using GitHub and Travis in our organization. The branches are protected, and require Travis build to pass, then are merged automatically.
The problem is that, well, sometimes contributors decide that the best way to fix the build (testing) process is... ...to remove the tests from the .travis.yml! Yey.
Are there any mechanisms I could use to prevent one file on the branch the user have full access to from being overwritten? Or make .travis use the config from outside of the branch that is being built?
Assign a code owner to the .travis.yml file. PRs changing Travis configuration will not be mergeable without the code owner's approval
If you still want to ensure that collaborators get an approval on Travis changes and push new changes before merging, you should enable stale review dismissal
Related
I'm trying to prevent developers from directly editing and committing to the master branch in ADF.
There is a risk that users can accidently make changes in ADF by not creating a feature branch but instead working directly on master (I've done it myself!)
Is there a way to enforce this in ADF? I do have a branch policy on master that only allows merging via a pull request but don't think this stops developers from working directly on master:
Another way to achieve this is to require a reviewer.
Select "Branch policies":
Turn on the option "Require a minimum number of reviewers":
Set the number of reviewers to 1.
This example shows "Allow requestors to approve their own changes". This setting is optional. If you set it, the user is still prevented from committing to main/master, but can complete their own PRs.
You can deny the contribute permission for the user group in git repo. Check the following official documentation:
https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-permissions?view=azure-devops
Now I'm using Github and Circle-CI. And Git flow is simple, after unit test on Circle-CI is done properly, pull request is accepted and merged into master branch.
In specific branch names, Circle-CI skips test. However Github doesn't allow to merge into master until unit-test is done.
How can I manage this situation?? Sometimes I wanna merge something into master without test on Circle CI.
GitHub has an option to allow admins to override that restriction. You'd need to use that.
Regardless, it never hurts to test everything.
We have a GitHub project (master), every member of the team have a Fork of the project into their own repository.
Once a developer fixed something he create a new branch inside his local forked repo and commit that into remote repository and after that they request a Pull Request so that change go into the master reposiroty.
We publish to production "manually" once a week but we have had issues in production because accidentaly developer had committed to their forked repository and other developer with higher privilegies accept the changes and merge that into master repo, then someone else publish to production and he didnt knew that those new changes didn't passed to QA process.
So, what I want is to create like a Production Repository, so when we have the code in master repo that we know is stable and working then create like a Production branch so if by mistake something is commited and merge into master repo then the code for production publish is not affected.
Any clue or best practice to do this?
Not sure I'm understanding the question correctly, but you can add as many remote repositories as you like. There is a section in the Pro Git book called Working with Remotes that discusses this thoroughly.
In my experience, separating development and production code is typically done with a branching model such as git-flow. You can create separate repositories to solve this problem if you like, but doing so is unnecessary. This is because if developer A submits a PR that's merged by developer B, then developer C will get a non-fast-forward error when they try to commit upstream. This is called a subversion-style workflow. Per the docs:
Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.
If commits to the upstream branch are not being fetched and merged appropriately before pushing, then someone has likely taken it upon themselves to rewrite history.
Your git workflow is good enough to take care of this issue.
First, to fix the issue:
Treat unintended code push as bug and fix it as you would fix any other bug. Best person to perform this activity would be the developer who pushed that code. Developer can just fix it in their fork and submit a pull request. Try not to add any other unrelated code with this pull request.
About Production Branch or Repo:
I don't think you need another Production Branch/Repo (you already have one). As it happened with your current PROD repo, accidental code push can make it to new Branch/Repo too.
Instead use tags/releases feature in GitHub. Whenever state of code in master repo is prod ready, tag it and use the tag for production publish.
We have over 100 repos which follow the github workflow https://guides.github.com/introduction/flow/. Ideally, when people are merging their code, they'll also click the Delete Branch button, but unfortunately, that step gets missed pretty often. I'm looking for a way to automatically delete branches which have been merged to the master branch. I'm thinking it should either be an organizational level webhook or integrated into our existing Jenkins system. I'm hoping that someone has already written this tool. Anyone?
I have a set of documentation for my company's API, based on the excellent Slate framework from TripIt. Per instructions, I forked their repo and proceeded to customize it. That fork lives here.
The obnoxious thing is that when contributors in my organization do a new pull request, the "base fork" on the Github "Comparing Changes" screen defaults to TripIt's repository, not my fork. They've more than once sent pull requests to the wrong place. Telling people "don't do that" isn't a particularly reliable solution. How can I set the default for where PRs are based to my fork?
GitHub keeps track of forks made through their interface and assumes pull requests will be for that original repository. You need to tell GitHub that your copy is not a fork but rather a regular repository that just happens to have identical history. Sadly, GitHub doesn't offer a good way to just uncheck the fork link. I typically solve it this way:
Clone the repository, git pull, and ensure your local copy is completely up to date.
Delete the repository on GitHub.
Create the repository on GitHub using the exact same name. Ensure it's an empty repository (don't create a README or LICENSE file.)
git push all the content back into the repository. (You may need to switch to each branch and push it, and you also may need to git push --tags.)
FRAGILE: This approach will lose existing GitHub issues and pull request comments. If you're using these heavily, this approach is probably a bad idea, and you should contact GitHub customer support to help you instead.
It is unfortunate that GitHub does not provide a way to configure the default PR target repo.
If you can delete (or get the owner to delete) the original repo A from which B was forked, then that will do the trick.
If it is not possible/agreeable to delete A, but the owner of A is willing to do the following, then the fork link gets broken, on GitHub Enterprise at least:
mark repo A as Private
mark repo A as Public again
After doing this, repo B (which was originally forked from A) will default to opening PRs against itself, rather than A.
Note: if A itself was forked from something further back in the history, then unfortunately it seems that B starts defaulting to opening PRs against that repo once A has gone. The only solution would be to apply the above to all repos upstream in the fork tree :(
Your other developers seem to have forked TripIt's repository, so that is the source/parent of their work.
In fact, if you open your own repository, you will see it hasn't been forked at all (the fork count is 0).
When they issue a merge request, by default github shows that repository as source, and so the pull request isn't sent to you.
The simplest workaround in this case is to ask your dev's to fork your repository, and work on it.
Yes, it's a bad situation...
The only solution I know of (other than deleting the fork and recreating/pushing directly from a local clone as described here ) is to have the upstream owner make the original repo PRIVATE and then return it to PUBLIC. Taking it private breaks the link to forks permanently.
But of course that requires action by the upstream owner. Github should really solve this, but it's been an issue for a very long time.