iOS & Android Versions Numbers about snowflake HOT 9 CLOSED

In general, you should manage the version number for yourself
and maybe have a “build number"
but don’t just auto-increment that
rather use the build number supplied by the related service
in case of bitrise.io you can use $BITRISE_BUILD_NUMBER env
or you can export it as an environment variable with envman

from snowflake.

http://stackoverflow.com/questions/33821137/build-versioning-in-continuous-delivery/33821876#33821876

from snowflake.

https://gist.github.com/viktorbenei/d341e74c8321473c8a67

from snowflake.

Hi there,

I would really like to help, but first I would like to know why your fastfile uses so many sh commands. I don't really know why they are necessary and also what they do, so I am quite confused ;)

Our Fastfile looks something like this:

    sigh
    # use the UDID of the newly created provisioning profile
    ENV["PROFILE_UDID"] = lane_context[SharedValues::SIGH_UDID]

    increment_build_number
    gym
    commit_version_bump
    push_to_git_remote
    pilot

What it does is:

1. Deals with Provisioning Profiles
2. Increment the build version number (an app can only be submitted with one version number once)
3. Commit and Push the version bump (with a message like "Deployed version XX")
4. Push the builded version to the AppStore (or Testflight, dependant on the lane)

I stripped away every kind of configuration, but I would be glad to add a PR if you are uncertain, so that we can discuss this more on a code level.

Have a nice day!

from snowflake.

That's a good question! When I first was working w/ Fastlane it looked very similar to what you have except for the push_to_git_remote as I worried about the webhook kicking off another build and end up in a never ending recursion.

I've never worked w/ Apple before so all this Cert, App Id, Provisioning, etc is new to me.

When I was working w/ Fastlane on Bitrise, and it included the same steps almost exactly what you have, I went through a large number of builds and each build would generate a new Cert, App ID, and Prov Profile - I ended up w/ a bunch of them all defined here: https://developer.apple.com/account/ios/certificate/certificateList.action. I had no idea which ones were active or in use or even if I needed them all.

When I mentioned this to the Bitrise.io CTO, he showed me how Bitrise handled it which is what I'm doing now. The advantage I observed following my current approach, if you watched the videos, is that I let XCode build the 3 artifacts and during the build step those artifacts are utilized.

Once I went that route I was able to get the apps running on the devices. Rather then beat my head against the wall, I opted to share what I had and hope someone could help clean it up.

As I mentioned in the video series on CI w/ Bitrise.io, the current implementation is just a base line to grow from, it's definitely not the end game - eventually I want Fastlane to do all the work.

If you could enhance our Fastlane implementation I'd be very grateful!

see #26

from snowflake.

Nice to know, we ran into exactly the same issue. The reason was that fastlane somehow didn't found the provisioning profiles it had created earlier. If I remember correctly the ENV line fixed this issue, or am I wrong @dbanck?

If so I would rewrite the fastlane config to use the more verbose approach fastlane provides and add a deploy script to the package.json, so one can easily deploy it from the command line.

from snowflake.

sounds good.

About that push_to_git_remote - are you using the Github webhook to kick of the build? What kicks it off?

from snowflake.

Well, we kick it of manually, this could introduce some kind of recursion in this case. But if the commit messages all have the same format, I think we could easily check if the name of the last commit matches and then ignore it. Or even better check if there is any valid commit since the last build was pushed.

from snowflake.

This can be done manually.

from snowflake.