I'm using Fastlane and deploying beta versions to Crashlytics from different branches.
The problem is, I want to keep consecutive build numbers no matter what branch I ran Fastlane from.
I couldn't find a way to fetch the build number from another branch's plist file.
Eventually I managed to solve it by making the master branch my one source of truth.
When running fastlane from a different branch (not the master), I switch to the master branch and increment the build number then go back to the branch and increment it as well.
Related
I have two different branches release/ver1 and release/ver2 and code base are completely different.
My requirement is to merge to the following:
1) Merge release/ver1 branch to the master and do the build.
2) Followed by the same day, Merge release/ver2 branch to the master and do the build.
Note: I can merge only to the master ( web hooks PR notifications are configured like this and I cannot create new release branches and merge to it)
Whenever I merge, I am getting merge conflict and every time, I need to manually resolve the conflict and as the code base are totally different, it takes lot of time to resolve manually the merge conflict error.
What would be the best resolution for the above situation?
Try at least to activate first git rerere
cd /path/to/repo
git config rerere.enabled true
If the same conflicts are involved in your different merges, git rerere would have recorded their resolution and can apply them automatically.
See "Git Tools - Rerere".
I have a project on github with two branches (dev and master), where code was in sync prior to adding some new features to dev. For a few months, I've been adding new features on the dev branch, which consisted of changes/updates to existing files, deleting some files, and creating new files, all on the dev branch. Everything is working great on the dev branch and now it's time to apply these changes to the master branch.
Since there are a lot of changes, I am trying to see all the differences visually between the dev and master branches, so I can apply the specific changes from dev to master without missing anything. I don't want to override master with dev, as there are some master specific files, so just the new things in dev should be applied to master, but I want to do it where I can see the compared files visually to ensure everything is looking right.
Any idea how to accomplish this?
Create a new branch from develop named release/may6. This way, you can commit changes to release/may6 without actually impacting your master branch.
Commit any master-specific differences to release/may6 and use the GitHub compare UI to see the differences between your working release/may6 branch and master:
https://github.com/orgname/reponame/compare/master...release/may6
Once you are satisfied that this view shows the correct master-only differences between release/may6 and master, simply create a Pull Request from that same compare UI which merges release/may6 into master.
I've recently transitioned from XAML builds to v.Next builds. I've always kept one build definition per branch but I see the new system has the ability for a single build definition to trigger on multiple branches and pull requests.
Is this a good idea? What are things to watch out for and the best ways to set this up?
The first couple concerns that come to mind are:
1) Version numbers. How would I handle scenarios such as an old maintenance branch versioning as 1.0., master versioning as 2.0. and a dev build as say 0.2.* so I don't confuse build artifacts? Is there a better way?
2) What if the repos tree has changed? What if master expects to build a .sln in one folder but a dev branch has since moved it to another folder?
Any other concerns and resolutions?
Single build definition to trigger multiple branches and pull request can make VSTS build more flexible. You can choose the way as you need:
If you want to build a certain branch for a build definition, you can specify the certain branch name. Assume if you only want to build master branch, you can specify master branch in Get Source step (for manually build), or specify master branch in Branch filters (for CI build).
If you want to build multiple branches in a build definition (for CI build), you can specify the branches in branch filters on Triggers Tab.
If you want to verify a PR before merging, you can add build validation for branch policy.
For your concerns:
Even a build definition can trigger multiple branches, but for a certain build, it build a certain branch after changes are pushed on this branch. And you can detect which branch is actually build, and update branch version number correspondingly.
Such as you have a build definition which can trigger to build both for master branch and dev branch. After pushing changes to master branch, a build will be queued for master branch. And you can get the branch name by some ways, so you can increase the version number correspondingly.
You can not only specify which branches can be triggered in your build definition, but also specify the folders which can be triggered in path filters. Assume there are folderA and folderB both contain .sln, you want to trigger build only when the .sln file changes under folderA, so you can specify branch filters and path filters as below:
For the situation: multiple branches can be triggered by a build definition, you can add a PowerShell task to detect which branch is building. The script as below:
$head=$(git rev-parse HEAD)
$sha=$head.Substring(0,7)
$branches=$(git branch -rv)
for ($i=0;$i -lt $branches.Length; $i++)
{
if ($branches[$i] -match $sha)
{
$tbranch=$branches[$i] -split "\s+"
$local=$tbranch[1] -split '/'
$br=$local[1]
echo "You are building $br branch"
break
}
}
This part,
Is this a good idea? What are things to watch out for and the best ways to set this up?
is off-topic (too broad/primarily opinion based), so I'm ignoring it and answering the two concrete scenarios you outlined.
Not really sure what you're asking. Release definition environments can be set to trigger on branches (artifact triggers), so if you have different release requirements for older branches, you can have different release definitions or simply an alternate pipeline within a single release definition.
You can specify wildcards in the Visual Studio Build step so you can specify, for example, **/*.sln. That will find any .sln file under any folder.
We are hosting a c/c++ based repo with multiple branches in Github , while doing CI , there are usually on the average 10 pull requests in each integration build , and if something fails , we have to track it in all of the merged PRs to figure out which one did the mess , i want to work it programaticaly so that i can know which pull requests fails the build. What can be the best approach to work on this problem.
One thing that i forgot to mention is that each PR is individually build and tested already before the merge into feature branch.
Thanks.
The best approach is to change your process a bit and only allow merging of Pull Requests that:
Build without errors (including running integration tests)
Are rebased to fit on the tip of your master branch (fast forward commits only)
Since the branch build without errors, and it was rebased on the latest master, merging it will never break master. Unrebased branches that are seemingly without conflicts can still break things if changes in not directly related files conflict with each other as the conflict algorithm is pretty simplistic.
Lacking that, git also has an option that can be used during an interactive rebase to run a command (the exec option) after each rebase step. In other words, you could rewind your branch back to a known working state, and then let git apply each commit in turn and run a command that checks if everything passes your tests with the exec option.
In this way you can automatically discover which commit broke your tests.
Me and my friend are two days into using Git now but we still lack the know-how to use it properly and utilize its full power though it is a tremendous step in the right direction, compared to using Facebook messages to sending and syncing files. We have searched over the net and most of the guides for Egit either assume you work alone or that someone else clones and branches off to their own repo. However we are collaborating on the same project (a 2D RPG) and don't know how to properly use Egit to work together. Some of the problems we face:
1. We had the exact same copy of the project, he changed some of the methods we used, I changed some of the classes and resources we use. He committed and pushed to repo first. Now I cannot push or commit or even pull because of conflicts in the files (repo vs local) which Egit complains must be resolved.
2. How do you properly synchronize code that you are collaborating on? Lets say either one of us is first out to push to repo, what must the other (the puller) do to make sure his own code is not completely overwritten, only accept parts that have changed, parts that we think should be changed.
3. Do we always have to make a (new) local branch, pull to this, see changes, and merge the changes we want with the master/main? How do you properly do this.
Any input is most welcome, we are already much more efficient with our broken knowledge, more will only do good :)
Ok here are my answers:
We had the exact same copy ... because of conflicts in the files (repo vs local) which Egit complains must be resolved.
First you should make sure you use separate branches so that you can always commit.
Then you have to resolve any conflicts when you merge.
How do you properly synchronize code ...
Use separate branches to make sure code is ok before you pull it into master branch.
Do we always have to make a (new) local branch ...
Yes, git is built on the assumption that this is the best way to work. "Everything is local"
This is the way I or we usually use branches:
Main dev branch (Master)
Project branch, used to merge in features added by this project. When all features have been added and seems to work this is pushed/merged into the master branch.
Developer branches, every developer has his/her own branch to develop a specific feature before pushing/merging that into the project branch.
What could sometimes be good to have is also specific release branches. I.e. when a project has merged all added features into the master branch and everything seems ok, a release branch is created for regression testing. This branch will eventually contain the released software when all testing has been done.
The benefit of doing a separate release branch is that the main branch can continue to be developed, but if a fast bugfix has to be done on an earlier release it can be done on that release branch and then later merged into the master branch.
//jk