I have 2 repositories.
When I make changes in the main repository, I want to clone change and make a pull request in the second repository automatically using GitHub action.
How would you implement such a workflow?
You could achieve that that through a combination of GitHub Actions (hooks executed on the GitHub server side)
on your repo1, you can associate on each push a actions/github-push workflow, in order to push to repo2 whatever was pushed on repo1
on your repo2, you can associate a vsoch/pull-request-action workflow:
This action will open a pull request to master branch (or otherwise specified) whenever a branch with some prefix is pushed to.
The idea is that you can set up some workflow that pushes content to branches of the repository, and you would then want this push reviewed for merge to master.
Related
I am trying to clone a repository from another git user (name him Bob). After I made some changes to the forked repository, I wish to make a pull request and allow Bob, the original git user from whom I forked the repository from, to accept and merge the changes.
However, I am not sure if Bob is making changes at the same time. How can I know if these changes are also 'synchronized' with mine, and if I can do it from the git commands?
In other words, before I hand it to Bob, I wish to ensure that I have Bob's latest version and ensure a smooth merge on his end.
Bash
$ git pull
Currently, when I type the following command, maybe I get the changes pulled under my changes, but in this case, could this command be a 'rebase' !?
It isn't your responsibility to manage concurrent changes in this way.
You are working on your cloned copy of the repository. You've settled on what changes you wanted to make and you've committed them to your copy.
Now, by creating a pull request (PR), you are sending a message to the original owner that your changes may be of interest. They will review the changes, and decide whether to accept or reject them. Your only responsibility is to create the PR.
If they have indeed been making changes to their repo while you had it checked out, and if their changes are incompatible, then it's their responsibility to reject your PR.
Before you submit the PR, you may sync any changes they've made to the repo into your cloned copy. That's what git pull is for, and it does make it more likely that the PR you end up submitting will be usable or acceptable.
If there have been changes made remotely which are incompatible with your changes, then the pull will fail. At that point you can try to resolve the conflicts, or email the owner to see what they were for, etc.
But while this is usually recommended, and while many repo owners may reject a PR if you didn't do git pull first, it isn't in any way a requirement for submitting a PR.
With a repository already cloned, if anybody may be making changes in the remote, you can simply type git pull followed by the name of the branch, cheking for new changes and download them:
$ git pull origin master
Then you will have a new remote branch with your changes, to check the current remotes type:
$ git branch --all
remotes/origin/HEAD -> origin/master
remotes/origin/master
NOTE: If you or another person are modifying the same line of the same file, git may need to do a recursive strategy and you will have to solve a conflict first.
the git pull is two combined commands git fetch and git merge
So, basically, you are doing a merge operation
To do a rebase you can use git pull --rebase
If I create a feature branch that has changes to workflow, is there a way to test it before merge? I have added on pull request to workflow but it has no effect.
If you want to test a workflow implementation or workflow update on a branch, before merging it, an easy way is to use the push trigger with the branches subtype:
on:
push:
branches: [<BRANCH_NAME>]
A workflow with this implementation will trigger for every push / update to the branch you're testing (for every commit pushed after opening the pull request as well).
Then, once you have validated the workflow using this implementation, just comment or remove the trigger to use the one you wish to maintain after the merge.
I am using TeamCity Enterprise 2021.2 (build 99542) and Bitbucket Server v7.14.0. I have a build configuration in Teamcity with 3 VCS roots: Repo1, Repo2, and Repo3. Each repo has a "main" branch, which is the default branch for all 3 repos. Repo 1 and 2 have a branch called "feature1".
If I set the branch specification in all 3 repos to refs/heads/* and set up a VCS trigger to Repo1 with the filter as +:* the desired behavior is achieved. A build is triggered when a change is made to feature1 in Repo1, and the build checks out feature1 on both Repo1 and Repo2, while main is checked out on repo3.
The problem is that I only want to trigger a build when a pull request is created or updated in Repo1. So, I use the Pull Request build feature to trigger with any pull request in Repo1, and set the branch specification in Repo1 to refs/heads/main (so duplicate builds aren't triggered) This results in almost the desired behavior.
I create a PR for feature 1 in Repo1 in bitbucket. And a build is triggered. The problem is that feature1 is only checked out in Repo1 but NOT Repo2. Is there any way to configure a VCS root for Repo2 to check out the same branch that is being used on Repo1 while builds are being triggered by PRs to Repo1?
I suspect the problem is related to some of the TeamCity build configuration variables. In the first case with the expected behavior, teamcity.build.branch is set to refs/heads/feature1. yay. In the second case, teamcity.build.branch is set to pull-requests/## while teamcity.pullRequest.source.branch is set to feature1.
It is not even a problem of variables, but a problem of the build (logical) branch.
If you are using the Pull Requests build feature it (internally) expands the branch spec of the VCS root in the context of your build configuration with patterns that include refs/pull-requests/123/from kind of branches provided by Bitbucket Server for pull requests.
So the logical branch name for the build becomes pull-requests/123, not a source branch of the pull request. As other repos do not have such pull requests in them, for them default VCS branches are selected. Which is in most cases ok, as such things as multi-repo pull requests are not supported by any VCS hosting. Not in my knowledge at least. In our opinion in most cases the following improvement could be useful for many users: to fall back to a VCS branches that match the target branch of the pull request instead of the default branch of the VCS root. This is to be discussed if such feature requests appear.
Anyway your case is different and it seems you want to use source branches in all three repos. If the following feature request is fulfilled it may satisfy your needs: https://youtrack.jetbrains.com/issue/TW-70491
We are currently working on it and it may appear as an experimental feature in one of our bugfix releases soon and as a proper feature in the next feature release this year. Please follow that issue to keep updated.
Cheers,
Anton
I currently have my BitBucket set up to follow the Git flow model (https://datasift.github.io/gitflow/IntroducingGitFlow.html) and have my Bamboo CI running against the develop branch.
What I want to know is if I can set up BitBucket to only approve and/or merge a pull request from a feature branch if that merge would not break the build on the develop branch.
So if we have a pull request to merge branch feature/amazing-new/feature the pull request will only be closed and the branch merged in to develop if Bamboo can do the merge and build successfully.
I've had a look around and only seen answers that refer to build plans that run against the feature branch itself and the BitBucket docs only have paragraph covering builds and pull requests: https://confluence.atlassian.com/bitbucketserver/checks-for-merging-pull-requests-776640039.html
Bamboo can be configured to build merge result: https://confluence.atlassian.com/bamboo/using-plan-branches-289276872.html#Usingplanbranches-Branchupdater
When new commit in feature branch detected it will merge feature branch to master in working copy, build and send result to Bitbucket. At Bitbucket side you can configure pull request settings to not allow PR merge if there're broken builds.
I have configured a Bitbucket Server and Teamcity as CI.
Teamcity also builds all commits, which does work very well.
Now I want to build the "Merge commit" which will be generated of a Pull request, before the Pull Request gets merged.
bitbucket creates pull-requests/<pr number>/from branch for every created pull request.
so you can add to vcs root branch specification rule "get only PR branches"
and then add vcs trigger to run it automatically on every new commit in pull-request