I want to automatically merge commits from master into another parallel branch which is used for different deployment strategy. So essentially whenever there is a change in master I want that change to be merged into one more branch automatically.
Is there a way in Github UI to do so?
Github does support automerge, but only for Pull Request.
You might check out a GitHub Action like action-automerge
GitHub action to automatically merge the source branch into a target branch every time a change is made.
You can add a GitHub Action workflow to your project in order to enable that "action-automerge".
That being said, maybe you have other approaches which would be simpler than merging master/main. Using the same branch but with a deployment script able to detect its execution environment would be easier.
Related
Github has the option to allow a PR to be squashed when merged ("Squash and Merge")
Is there anyway I can configure the branch so it only allows the "Squash and Merge" option?
My scenario is this
we have a develop branch, that feature requests are pushed to
sometimes developers will forget to choose "Squash and Merge" and will commit their feature branch, with 10-20 tiny commits to the develop branch.
These changes eventually get merged to master, and feature history becomes hard to read
I have looked in hooks in branch protection rules, but didn't see any such option
Unfortunately the option to change what type of PR merge is available on Github is set on a per repo basis. Since PRs are a github thing, not a git thing, I can't think of a way that you'd be able to do anything with githooks either.
I don't see a great option for your workflow as long as you require the intermediate develop branch that eventually gets merged into master. Workflows that have multiple layers of PRs get messy on Github. The one real option would be that you require squash to merge on Github PRs and then the regular merge from develop to master happens outside a PR (could be local on a machine or via a Github action potentially).
But, your best option if this is really a big problem may be to modify your workflow. One common workflow would be that master is the development branch. Then when it is time for a release a release branch or tag, depending on your needs, is created from master. The you will have no issue turning on the repo wide requirement for squashing.
I am creating a new git workflow. And just like any other piece of code, I want to test it separately without having to merge it into master first.
This will also help if I have to make few corrections if something doesn't work in the workflow yaml.
Here is the mechanism that I am looking for:
main branch has .github folder which contains all workflows
I create a branch and add my workflow to .github folder
Now I should be able to see(somewhere on Github) workflows from my branch running
When I know that workflows are working fine, I merge my branch in master
Now under github 'Action' tab, new workflows will reflect
Is there a way to do this?
I am actually doing workflow testing all the name, as you can see this test workflow workflow-level-notification is not merged into master branch (ie default branch), and I can still see the workflows in the UI.
Like GuiFalourd said, you can also use act to do the local testing as well. But working directly in the github repo is not that bad. (you can delete the workflow after)
If you would like to test non PR triggerd actions you can simply update your default branch temporarially, run the actions for test, then when you are done switch back.
We use an internally hosted github server for our SCM, Jenkins for our CI and Git-Flow (via maven's jgitflow plugin) for our branching strategy.
I have a Jenkins build job set up such that it takes the git branch as a parameter and then can check-out and build the correct branch based on what was selected.
.....
.....
.....
What I would like - is to automatically trigger the BASE_JOB to build only the branch that's been pushed. So far, I have been unable to find any way to do this.
If I set up to build when changes are pushed to github, then the job will simply rebuild whatever the last built branch was regardless of the branch that's been pushed.
I've seen some plugins for Jenkins that will auto-generate template jobs when new branches are created - but I think it is over-kill to necessitate having a job per currently active branch.
Is there a way to pass a branch parameter to the "Build when a change is pushed to GitHub"? Or some other way to work around this apparent limitation?
Thanks!
Check with these settings and see if it works.
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?
Caveat: I am fairly new to both git and GitHub.
So, in my current setup, my team uses git flow Hotfixes (usually started and finished by a graphical tool such as GitKraken or IntelliJ) to make changes that have to be merged into two branches and pushed upstream in both. So for example the flow would be:
Pull latest from master
Start hotfix
Commit changes
Merge hotfix branch into both master and develop and push both upstream
We're now looking at moving our code into GitHub and would like to start using Pull Requests, for a couple of reasons:
CI hooks to run tests and stuff
a place to put code-specific comments not directly related to the underlying "issue"
avoiding the need for everyone to constantly be pulling the latest master/develop to their local machine so that they can merge changes
But in the case of Hotfixes, I'm not sure what to do because I'm merging into two branches but it really is one "action" so manually creating two pull requests seems weird, particularly since step 4) in our current flow is a single click.
Is there a smart way of handling this? My ideal case would be that pushing the Merge button on the Pull Request would just merge into both, but that doesn't seem to be an available option.
As you mentioned, a Pull Request has only one target branch, so you won't be able to push the hotfix to both master and develop by merging one Pull Request.
I'm also surprised you mention your step #4 - merging the hotfix branch to both master and develop and push upstream - is one action. While there's a high chance the merge from hotfix to master won't run into merge conflicts, I can't say the same for the merge from hotfix to develop since it could have been worked on since the last deployment to production.
My recommendation would then be the following:
Create one PR from hotfix to master and have someone review it to validate the fix
Once it's merged into master, create another PR from hotfix to develop and see if you run into merge conflicts
If that's the case, resolve the merge conflicts so the PR ends up in a state to be merged, and have someone review the PR
If there's no merge conflicts, then have someone review the PR
An alternative solution, if you really want to go down the automated path, would be to leverage both GitHub webhooks and API.
The webhook would allow you to be notified when a PR is merged. You could inspect the payload to make sure that the base branch starts with hotfix/ and the target branch is master. You could then react to that event by using the API to create a new PR from the same hotfix branch to develop.
It will involve some development, and the effort might not be worth since creating a PR via the UI is still quite easy and quick.