I want to create branches for modifying the exisiting raml,
can any one help me how to create a new branch before modifying new changes directly to the master instead I can create feature branch or some other branch and
also I would like to know how to merge the new create branches to the existing branch
Example:
Master>UAT>STAGE>INT>DEV--- I need to create this as constant
and create feature whenever there are any changes requested
I need to create all this branches
but I have only one branch as Master
So if any of them want to update existing raml they should be able to create one feature branch and sent and approval request to merge any of the existing.
In Anypoint API Designer you can create branches from the master branch, by following the instructions at https://docs.mulesoft.com/design-center/design-branching, however note that the same page mentions explicitly that you can not merge changes from a branch back into master.
Related
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 currently setting up a CI system that will check for a passing deployment against a test environment as part of a pre-merge pull request check. This system is using Bamboo and Bitbucket, and will stop devs from merging their feature branches into the main branch if this validation fails. However, I am running into the (possibly common on my project) corner case of multiple pull requests being open at the same time, passing validation, and then being merged. In this scenario the PRs might all separately pass validation while all of them combined would break the build (I.E: PR#1 modifies a method name referenced by PR#2).
Is there a way to configure Bitbucket / Bamboo to rerun builds on pull requests if the target branch has been modified since the check last ran?
On git (bitbucket) level you could make sure to synchronize any feature or bugfix branch with an outgoing pull request by merging the latest common target branch (for example develop) immediately after a successful pull request merge to this target. This way you invalidate the 'latest' build result on feature or bugfix branches and they would be re-built because their git commit hash has changed. If any re-build of the feature branch fails, it won't be merged.
Ulrich
// Izymes - our mission is to eliminate boring from work. We build apps that turbo-charge team velocity through contextual automation.
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 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.
I have a Gerrit project without any dashboards defined. To make the differentiation between multiple projects on the same Gerrit server easier I would like to create a new dashboards for one of the projects.
The official documentation (at least as of v2.13.5-2456) assumes that the necessary branch where the dashboards are to be created already exist, which ist not the case on my installation. As such, the necessary steps for the first dashboard for a project are omitted there.
So the question is: What are the necessary steps to create a first dashboard for a project? Are there any pitfalls? If so, how can they be avoided?
The biggest problem is creating the new meta branch where the dashboards will be housed. For that you need to make sure the user has the following access rights for the reference refs/meta/dashboards/*:
CreateReference
Push
Now check out your project as usual with git clone ssh://<user>#<server>:29418/<path/to/project> (you may want to adjust the port as necessary). You will have the current master branch in your working directory. However, the dashboards branch only works if the only files in it are actual dashboard configurations.
To solve this you have to create a new orphan branch, which does not have any history or files in it. That can be achieved with git checkout --orphan dashboard_local.
On this branch you can create your dashboard configuration with the syntax as documented in the official manual. Commit this file and make sure that no files other than dashboard configurations are in this branch.
Now this branch needs to be pushed to the server. You can use the regular Gerrit syntax here: git push origin HEAD:refs/meta/dashboards/<group>. Using the <group> identifier you can group several dashboards together in the Gerrit Web-UI.
If you made no syntax errors your dashboard should now show up and new dashboards can be added to this existing branch.
Based on:
An explanation of emtpy (orphaned) branches in git
MediaWiki Help on Gerrit dashboard