I have a project which includes two repos, let's say their status are version1#repo1, version1#repo2
Now I have to commit two changes to those two repos to make history become version2#repo1 and version2#repo2.
Only version2#repo1 + version2#repo2 can be built correctly, so those two commits are interdependent and they must be merged same time.
Is gerrit able to handle this situation?
Yes, Gerrit supports that use case. Changes can be grouped via topic: https://gerrit-review.googlesource.com/Documentation/intro-user.html#topics
But building must be done on your own in your build scripts.
Related
Please read carefully as I believe my use case is unique and I have tried searching a lot on how to do this, but I am still unsure.
Generally, I am trying to set up a repo for a group of developers to work on and have it contain CI checks and require reviewers. However, I have run into some issues with how Github enforces branch protection. On top of that, I cannot use Actions as we are using a self-hosted Enterprise Github through an organization.
My desires:
Use Jenkins (which is already set up and building) builds as checks for PRs. If the checks don't pass, you cannot click merge on the PR.
Allow pushing to a branch that I have a PR up for so the author can push changes based on PR comments.
Require two approvals from maintainers. You cannot click merge without these.
It seems I could protect a master branch for example. However, I would like to enforce the PR checks whenever a person chooses to make a PR. For example, from one dev branch into another dev branch.
Use case:
An author sets up a PR for merging a branch some-work into dev. Jenkins builds the HEAD of the branch some-work to evaluate the checks. I would like to enforce this PR to have two approvals from maintainers. So, those reviewers make some comments and request some changes. The author makes those changes and pushes a new commit to the some-work branch. Jenkins runs on the new HEAD to reevaluate the checks. Then, if-and-only-if the two reviewers approve and the checks pass can the merge button be clicked.
What I have tried:
Using Github branch protections: the required approvals and the required status checks. However, this prevents any pushing or force pushing to the branch being developed on. I could just apply these protections to master, but I also want these checks part of any PR (even dev2->dev1, for example).
Github actions, but these are not available in the self-hosted enterprise Github I have to use.
What I understand:
I understand that I can protect master, for example, in this manner with the native Github branch protection. However, if I want master to be something that always works, it is understandable that developers would break up a feature into multiple branches. They would also want their follow developers to review it when merging it from their branch to an intermediate (non-master) branch. Then the actual branch being merged into master consists of code written by many developers.
Thank you all in advance for your time and help. :)
Using Github branch protections: the required approvals and the required status checks.
However, this prevents any pushing or force pushing to the branch being developed on
But... that issue (not being able to push a protected branch) could be part of a possible solution.
I would make jenkins create/reset a PR branch based on a push on a topic branch (like some-work-pr, based on some-work)
some-work is not protected, and can receive commits at any time
some-work-pr is created by Jenkins protected, and cannot be modified: compilation/test/review/approval happens here.
PR would only be done from xxx-pr branches (protected PR branches created/managed by Jenkins), while other topic branches continue to evolve.
You can only enforce these policies with branch protections, so if you want to enable required CI checks before merging a PR for all branches, then you need to protect all branches (e.g., with the pattern **). In that case, you'll need to have developers use a forking model for your repositories so that they can push code to their forks and then merge in the changes via pull requests only.
Note that if you adopt an approach where projects are implemented as a set of small, incremental changes that are merged frequently and use feature flags to control whether the code is enabled, then as a practical matter developers will only merge into the main branch and you can get away with only protecting the main branch.
Within Bamboo I have several linked repositories. Each one of these repositories are connected to a specific branch, which you have to set through Bamboo's web interface. Is it possible to dynamically choose the branch without having to go in and change the linked repo branch every single time?
Yep, Bamboo supports branches, both manually added and automatically detected without new repository needing to be created. You just need to let it know where you keep branches in your repo.
https://confluence.atlassian.com/bamboo/using-plan-branches-289276872.html
Scroll down to managing plan branches in bamboo. They reference feature branching at the top of this article, but you don't have to be using that paradigm to get some use out of the branching support in bamboo.
I have 3 github repos and my build need to include all of them. How can I configure a free style project on Jenkins to listen on more than one github repo commit? I want to trigger the project on any commit to any of these three repos.
I'm afraid you cannot do that in the same Job. If u want three separate repos to be monitored then u have to have three separate Free style projects.
In case there are three branches then we can monitor them. Let me know if you would like to know more.
We have been using TFS 2010 to manage work items and sprints for a while now and have recently added on a dedicated QA person. What I need to be able to do is to either create a build definition that I can run on a scheduled basis (Tuesdays at 9pm for instance) that will only build and/or deploy the Work Items that are in a State of "ReadyToDeploy". Or a way to get a list of files to push based on the TFS API.
My end goal is to have a way to automate the release process so that only the items that have passed QA are sent to our staging environment weekly. Then the customer or QA can approve that the items work in staging which is a mirror of production, and another process or build definition will deploy those items which will be in a different state.
I have modified the work items and work flows to accomplish the different states, but I am having an issue getting either a build of just the fixes or a list of all the files to push based on the state of the work item.
I am open to any ideas or solutions for this, the alternative is that I have to manage the list of files and manually push files every week and I am trying to get away from that.
Thanks,
Edit: The way we have it setup now, is that each developer has their own branch and own website, our software is server based and has to be run on a particular server. Our Trunk is linked to the main dev website. This is where QA initially does their testing to move an item to the ready to deploy status. When a dev is ready for QA they check in their changes in their branch and merge into the trunk. The builds are created off of the trunk at the moment. On our deployment nights I open up the trunk website in VS and do a publish then take those files compared against a list the developers have given me and ftp the compiled files to our production server.
I could be wrong, but I am not aware of a way to tell a build to avoid certain changesets based on the state of an attached work item.
I think the only way you could achieve this would be to create a Release branch and perform a daily merge of changesets that are in the "ReadyToDeploy" state. When you merge, you are able to cherry pick changesets, but they must be contiguous. This means that you would have to perform multiple merges to get the Release branch into the appropriate condition.
We have operated something similar for many years and it works well for us. Many people will tell you that it's bad practice, and it probably is, but that is for you to decide.
As for automating this for a build, I don't think it would be a trivial job. The hardest part will be the merge. You might think that there will be no conflicts as it is a one-way merge, but having done this for a number of years, I can tell you that conflicts do arise.
Step By Step Explanation
Create a branch off the trunk called release
When you want to do a deploy, merge from the trunk into release, but only cherry pick the ReadyToDeploy changesets. This may take several merges as the changesets must be contiguous.
Fire off a build / deploy of the release branch.
Repeat steps 2 - 3 as your release schedule allows.
You could do something automatic, it would require an extensive bit of coding. It would also require a branching strategy so that, Dev, Staging, and Production all come from their own branches.
Set up a process that uses the TFS API to scan for items in that state
Use API to Traverse Items to get check ins attached
Use API to Get latest of source and target branch
Use API to Merge by change set (identified in #2) (this is non trivial, have to handle lots of cases, but merging should all be 1 way with no conflicts, so doable)
Use API to Check In
Kick off Compile Build
If Compile Build Successful kick off Publish Build
To the best of my knowledge there is a major issue with this approach. Say you have two changesets: # 1 and 2. Both of them containing modification for the same file. Now changeset #2 contains its own changes plus changes from #1.
If you decide to pull in changeset 2 and skip #1 guess what's gonna happen. You are going to suck in changes from #1. This is obviously a problem.
We have 3 environments: dev, test, and staging.
I want to check in and out of TFS. When we make changes, I want to promote the code to the dev web server. Next I want to promote the changes to test, then to staging. Would it be possible to do this with Team Foundation Server?
Why on earth are people suggesting branching? You branch for different features or static branches for release snapshots.
Surely the differences between these environments are configuration items/files and settings within these. All you need to do is get your deployment and release management process in order.
Create appropriate MSBuild tasks and use TFSBuild (Continuous Integration) to call these to take care of outputting the correct config files for the Environment/Configuration you are building. You can trivially add another MSBuild target that deals with the appropriate deployment to the respective target environments.
You can manually checkout the code from each branch, make your changes subsequently to each branch, and checkin. Very carefully.
Much better is to have these 3 environments be branches of each other. (Typically you start with dev, and branch to the other 2 in turn). Then you can use the Merge functionality to merge (for example) your dev changesets directly to test, etc. At this point your Test modules (that need to be changed to match dev) are checked out, with the changes. Then simply commit the changes. Then repeat for staging and rinse. This is the suggested methodology for this common scenerio.
Two important notes:
Even though TFS if very server-centric (compared to SVN, for example), this merging functionality happens on the client. You need to have each branch mapped to your machine. After the Merge process is completed, you'll have uncommitted changes in the target branch until you check in.
In Microsoft's vision and in the example I give here, these branches are permanent. This was a change from my previous practice using SVN, where whole branches were created/promoted/retired all the time. In the TFS way, you create the Test branch and it remains, indefinately, the Test branch. It's never promoted; its changes are merged elsewhere.
Building is a separate action. You need to set up a separate build for each situation, though of course once you set up the first one the other two will be trivial. After your merge to staging, you'll then run the staging build. (From Team Explorer or in the Build menu). TFS is a bit heavy but once it is set up it does handle this situation very well, easy for a distributed team to merge and build quickly (with automated build tests, etc.).
Yes, this is possible, but you must manually check them in from one branch to another.