xcodebuilder 0.0.18 → 0.0.19

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 0d59aaff9c4a2068306dd0a2b76da9b55b067887
-  data.tar.gz: b7a552232e3d331c52ecf6c10145702534dbb3f6
+  metadata.gz: 5d00f503638861f5ae2c3388a735ce9148ead34d
+  data.tar.gz: 9e2c3f9ebbefd5f8deeb58b6b0759f8ae99a97e4
 SHA512:
-  metadata.gz: a34aeb8934fa4e1033c6b5bb9330683c35d53fe7daa43afdcbf2236a7bfcb2109fc16d36d7dea2f1b2b1ae55ad9c2a40e81c5eed57e1902957d00a8261fb1b33
-  data.tar.gz: 006e89e42ced76e226e84b084991fbf6531bd3c5f67d816f0784d21174cad79b44427f3d5512d2b40e448a83b17315f7bebad8d18cbb5aa2d3cc94b205b006f6
+  metadata.gz: 600405aa31e63323e562c98b4b2ffc97952a16b693b71e7379254e9077bbf4bddc84346f9c9270cf2425c6e4cea3e532c5706d001c784b23178e52915162c49b
+  data.tar.gz: e15b921f581ce76c9f099d5c85b95ac9071578a8c84ab1942f690c5c9f00fb6d66f1dbd821f0357bfc5a222de0bf1b8e7565c8b5284508774fe50f6a33dab566

data/README.md

@@ -1,233 +1,63 @@
-# BetaBuilder, a gem for managing iOS ad-hoc builds
+# xcodebuilder, a gem for managing iOS builds
 
-BetaBuilder is a simple collection of Rake tasks and utilities for managing and publishing Adhoc builds of your iOS apps. 
+xcodebuilder is a fork from [BetaBuilder](https://github.com/lukeredpath/betabuilder), heavily modified to be more generic and convenient.
+It was written to simplify CI for iOS and OSX project, as a mere ruby wrapper on xcodebuild.
 
-If you're looking for the OSX BetaBuilder app -- to which this gem owes most of the credit -- you can find it [here on Github](http://github.com/HunterHillegas/iOS-BetaBuilder).
+In a nutshell, it supports:
+* Building iOS and OSX apps
+* Uploading iOS apps to testflightapp.com.
+* Git tagging builds
+* Automatically incrementing the `kCFBundleVersionKey` key for your project
+* Linting and releasing a CocoaPod library
 
-**Note: As of release 0.7, support for Xcode 3 is deprecated. Xcode 4 has been out for a year, has got much more stable as of 4.1 on Lion (or 4.2 if you've been using the betas) and it's time to move on. Generating Xcode 4 friendly archives and builds in this release still needs a bit of configuration but will become much smoother in 0.8 once Xcode 3 support is removed.**
+All this is implemented in plain ruby, and distributed as a ruby gem, which makes it quite trivial to integrate that with `rake`, or do more complex things should you want to.
 
-## Motivation
+In short, xcodebuilder is the best thing since chocolate milkshake to setup your Cocoa CI tracks: it takes care of scripting xcodebuild, taking all this complexity away from you, while you still retain fine grain control over your build.
+You can pick your signing identity, add random extra params, upload your builds to TF (with or without DSYM).
+If your project is simple and you don't require any of this fanciness, your rakefile is about 15 lines short.
+If your project is complex and you require a bunch of fanciness, your rakefile is about 30 lines short. w00t!x
 
-The problem with using a GUI app to create the beta packages is that it is yet another manual step in the process of producing an ad-hoc build for your beta testers. It simplifies some steps but it still requires running Build and Archive in Xcode, saving the resulting build as an IPA package, running the Beta Builder app, locating the IPA, filling in the rest of the fields and generating the deployment files. Then you need to upload those files somewhere.
-
-As a Ruby developer, I use Rake in most of my projects to run repetitive, often build or test-related tasks and it's equally as useful for non-Ruby projects as it is for Ruby ones.
-
-This simple task library allows you to configure once and then build, package and distribute your ad-hoc releases with a single command.
 
 ## Usage
 
-To get started, if you don't already have a Rakefile in the root of your project, create one. If you aren't familiar with Rake, it might be worth [going over some of the basics](http://rake.rubyforge.org/) but it's fairly straightforward.
-
-You can install the BetaBuilder gem from your terminal (OSX 10.6 ships with a perfectly useful Ruby installation):
+The simplest is to integrate xcodebuilder within a Rakefile.
+Start off by installing xcodebuilder:
 
-    $ gem install betabuilder
-
-At the top of your Rakefile, you'll need to require `rubygems` and the `betabuilder` gem (obviously).
+    $ sudo gem install xcodebuilder
 
+Include the xcodebuilder gem by adding the following at the top of your Rakefile:
     require 'rubygems'
-    require 'betabuilder'
-    
-Because BetaBuilder is a Rake task library, you do not need to define any tasks yourself. You simply need to configure BetaBuilder with some basic information about your project and it will generate the tasks for you. A sample configuration might look something like this:
+    require 'xcodebuilder'
 
-    BetaBuilder::Tasks.new do |config|
-      # your Xcode target name
-      config.target = "MyGreatApp"
+Instantiate a builder object:
 
-      # the Xcode configuration profile
-      config.configuration = "Adhoc" 
-    end
-    
-Now, if you run `rake -T` in Terminal.app in the root of your project, the available tasks will be printed with a brief description of each one:
+    builder = XcodeBuilder::XcodeBuilder.new do |config|
+        config.app_name = "YOUR_APP_NAME"
+      end
 
-    rake beta:build     # Build the beta release of the app
-    rake beta:package   # Package the beta release as an IPA file
-    
-If you use a custom Xcode build directory, rather than the default `${SRCROOT}/build` location, you can configure that too:
+Build your project. This will package an IPA and drop it in ./pkg:
 
-    BetaBuilder::Tasks.new do |config|
-      ...
-      config.build_dir = "/path/to/custom/build/dir"
+    task :build do
+      builder.package
     end
 
-To deploy your beta to your testers, some additional configuration is needed (see the next section).
-
-Most of the time, you'll not need to run the `beta:build` task directly; it will be run automatically as a dependency of `beta:package`. Upon running this task, your ad-hoc build will be packaged into an IPA file and will be saved in `${PROJECT_ROOT}/pkg/dist`, along with a HTML index file and the manifest file needed for over-the-air installation.
-
-If you are not using the automatic deployment task, you will need to upload the contents of the pkg/dist directory to your server.
+Release your project. This will package the IPA, drop it in ./pkg, increment the build number and git tag the tree:
 
-To use a namespace other than "beta" for the generated tasks, simply pass in your chosen namespace to BetaBuilder::Tasks.new:
-
-    BetaBuilder::Tasks.new(:my_custom_namespace) do |config|
+    task :build do
+      builder.release
     end
-    
-This lets you set up different sets of BetaBuilder tasks for different configurations in the same Rakefile (e.g. a production and staging build).
 
 ## Configuration
 A full list of configuration options and their details
 
-`configuration` - (String) The Xcode Configuration to use (Defined on the Info tab of the Project)
-
-`build_dir` - (File Path) The directory the build output will be. (`:derived` for Xcode 4 for versions < 0.8)
-
-`auto_archive` - (true/**false**) Automatically archive when packaging
-
-`archive_path` - (File Path) Path to the Archives
-
-`xcodebuild_path` - (File Path) Path to xcodebuild, if its non-standard
-
-`xcodeargs` - (Arguments) Arguments passed to `xcodebuild` when it runs
-
-`project_file_path` - (File Path) Path to the `.xcodeproj` file
-
-`workspace_path` - (File Path) Path to the `.xcworkspace` file
-
-`ipa_destination_path` - (File Path) Path to output Packaged IPA to
-
-`scheme` - (String) What Scheme to use when building
-
-`app_name` - (String) The name of the app being built (should match the file name, less the `.app` extension)
-
-`arch` - (String) The architecture to build for, if different from project settings
-
-`xcode4_archive_mode` - (true/**false**) Use Xcode4's Archive mode
-
-`skip_clean` - (true/**false**) Skip the clean step when building
-
-`verbose` - (true/**false**) Increased output for debugging
-
-`dry_run` - (true/**false**) Don't upload to Distribution Strategy, just act like it
-
-`set_version_number` - (true/**false**) Attempts to set a version number, see below
-
-### Configuration (Testflight)
-Testflight presents its own set of options that can be configured
-
-`api_token` - (String) Can be your API key, but its recommended to use an `ENV[""]` variable
-
-`team_token` - (String) Your Team's Testflight API token
-
-`distribution_lists` - (Array) A Ruby array (`[1,2]` or `%w{1 2}`) of distribution list names for Testflight
-
-`notify` - (true/**false**) Notify the distribution list of this build
-
-`replace` - (true/**false**) Replace if an existing build exists with the same ID and version
-
-### Configuration (Web)
-Pushing to a web server has the following options.
-
-SSH keys will simplify authentication and make this process seamless
-
-`remote_host` - (String) Hostname for the server the build will be pushed to
-
-`remote_port` - (String) Port Number to use for SCP/SFTP
-
-`remote_installation_path` - (String) Remote Path
-
-### Configuration (RunTime)
-Certain configuration options are availabe at the command line, so that you can temporarily set them for a single run without modifying your configuration.
-
-Pass any of these in as environment variables:
-
-`DRY` - (true/**false**) Enable Dry Run
-`VERBOSE` - (true/**false**) Turn on all output; lets you see the clean, build, and signing output
-`SKIPCLEAN` - (true/**false**) Skips the clean step and goes right to Build.
-
-####Examples
-
-`rake staging:deploy DRY=true`
-
-`rake staging:redeploy VERBOSE=true SKIPCLEAN=true`
-
-## Xcode 4 support
-
-Betabuilder works with Xcode 4, but you may need to tweak your task configuration slightly. The most important change you will need to make is the build directory location, unless you have configured Xcode 4 to use the "build" directory relative to your project, as in Xcode 3.
-
-If you are using the Xcode derived data directory for your builds, then you will need to specify this. Betabuilder will then scan your build log to determine the path to the automatically generated build directory that Xcode is using for your project.
-
-    config.build_dir = :derived
-    
-This will become the default in 0.8.
-
-If you wish to generate archives for your Xcode 4 project, you will need to enable this. This will become the default in future once Xcode 3 support is dropped (deprecated in 0.7):
-
-    config.xcode4_archive_mode = true
-    
-If you are working with an Xcode 4 workspace instead of a project file, you will need to configure this too:
-
-    config.workspace_path = "MyWorkspace.xcworkspace"
-    config.scheme         = "My App Scheme"
-    config.app_name       = "MyApp"
-    set_version_number
-If you are using a workspace, then you must specify the scheme. You can still specify the build configuration (e.g. Release).
-
-## Automatic deployment with deployment strategies
-
-BetaBuilder allows you to deploy your built package using it's extensible deployment strategy system; the gem currently comes with support for simple web-based deployment or uploading to [TestFlightApp.com](http://www.testflightapp.com). Eventually, you will be able to write your own custom deployment strategies if neither of these are suitable for your needs.
-
-## Setting version numbers automatically
-
-You can use betabuilder to set a build number using Git's `describe` system.  In order for that to work, at least one `tag` must exist somewhere in the git hierarchy for the branch being built from. 
-
-Also, you are required to set your `CFBundleVersion` to `${VERSION_LONG}` inside your `Info.plist`.  To accomodate manual builds, add a `VERSION_LONG` Build Setting to your app's Project, and treat it as you normally would your `Info.plist` version number.
-
-Once a tag is created and your App is configured, simply add this to your BetaBuilder config and it will use Git to generate the 
-
-	config.set_version_number = true
-
-It will generate a version number like: `1.0-15-g6b3c1bb`. 
-
-* *1.0* is the most recent tag
-* *15* is the number of commits since the tag was generated
-* *g6b3c1bb* is the beginning of the hash of the last commit.
-
-### Deploying your app with TestFlight
-
-By far the easiest way to get your beta release into the hands of your testers is using the excellent [TestFlight service](http://testflightapp.com/), although at the time of writing it is still in private beta. You can use TestFlight to manage your beta testers and notify them of new releases instantly.
-
-TestFlight provides an upload API and betabuilder uses that to provide a `:testflight` upload strategy. This strategy requires two pieces of information: your TestFlight API token and your team token:
-
-    config.deploy_using(:testflight) do |tf|
-      tf.api_token  = "YOUR_API_TOKEN"
-      tf.team_token = "YOUR_TEAM_TOKEN"
-    end
-    
-Now, instead of using the `beta:package` task, you can run the `beta:deploy` task instead. This task will run the package task as a dependency and upload the generated IPA file to TestFlight. 
-
-You will be prompted to enter the release notes for the build; TestFlight requires these to inform your testers of what has changed in this build. Alternatively, if you have a way of generating the release notes automatically (for instance, using a CHANGELOG file or a git log command), you can specify a block that will be called at runtime - you can do whatever you want in this block, as long as you return a string which will be used as the release notes, e.g.
-
-    config.deploy_using(:testflight) do |tf|
-      ...
-      tf.generate_release_notes do
-        # return release notes here
-      end
-    end
-    
-Finally, you can also specify an array of distribution lists that you want to allow access to the build:
-
-    config.deploy_using(:testflight) do |tf|
-      ...
-      tf.distribution_lists = %w{Testers Internal}
-    end
-
-### Deploying to your own server
-
-BetaBuilder also comes with a rather rudimentary web-based deployment task that uses SCP, so you will need SSH access to your server and appropriate permissions to use it. This works in the same way as the original iOS-BetaBuilder GUI app by generating a HTML template and manifest file that can be uploaded to a directly on your server. It includes links to install the app automatically on the device or download the IPA file.
-
-You will to configure betabuilder to use the `web` deployment strategy with some additional configuration:
-
-    config.deploy_using(:web) do |web|
-      web.deploy_to = "http://beta.myserver.co.uk/myapp"
-      web.remote_host = "myserver.com"
-      web.remote_directory = "/remote/path/to/deployment/directory"
-    end
-    
-The `deploy_to` setting specifies the URL that your app will be published to. The `remote_host` setting is the SSH host that will be used to copy the files to your server using SCP. Finally, the `remote_directory` setting is the path to the location to your server that files will be uploaded to. You will need to configure any virtual hosts on your server to make this work.
+More coming!
 
 ## License
 
 This code is licensed under the MIT license.
 
 Copyright (c) 2010 Luke Redpath
+Copyright (c) 2013 Olivier Larivain
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

data/lib/xcode_builder.rb

@@ -11,7 +11,7 @@ module XcodeBuilder
 
     def initialize(namespace = :xcbuild, &block)
       @configuration = Configuration.new(
-        :configuration => "Adhoc",
+        :configuration => "Release",
         :build_dir => "build",
         :xcodebuild_extra_args => nil,
         :xcrun_extra_args => nil,
@@ -241,7 +241,7 @@ module XcodeBuilder
     # runs a pod dry run before tagging
     def pod_dry_run
       print "Pod dry run..."
-      result = system "pod lib lint --only-errors"
+      result = system "pod lib lint #{@configuration.podspec_file} --only-errors"
       raise "** Pod dry run failed **" if !result
       puts "Done"
     end
@@ -251,6 +251,7 @@ module XcodeBuilder
       cmd << "pod"
       cmd << "push"
       cmd << @configuration.pod_repo
+      cmd << @configuration.podspec_file
       cmd << "--allow-warnings"
 
       print "Pushing to CocoaPod..."

data/lib/xcode_builder/release_strategies/git.rb

@@ -10,7 +10,7 @@ module XcodeBuilder
         end
 
         if @branch == nil then
-            @branch = "master"
+            @branch = `git rev-parse --abbrev-ref HEAD`.gsub("\n", "")
         end
 
         if @tag_name == nil then
@@ -34,6 +34,13 @@ module XcodeBuilder
         puts
         puts "Done"
 
+        puts
+        puts "Pulling from remote repo before pushing..."
+        result = system("git pull #{@origin} #{@branch}")
+        raise "Couldn't merge from #{@origin} #{@branch} - did somebody push a conflicting commit while I was building?" unless result
+        puts
+        puts "Done"
+
         # then push tags to the remote server
         print "Pushing tag to #{@origin} on branch #{@branch}"
         cmd = []
@@ -62,8 +69,8 @@ module XcodeBuilder
         @configuration.increment_pod_number
 
         # commit
-        print "Committing #{@configuration.info_plist} and #{@configuration.podspec_file} with version #{build_number}"
-        stage_files [@configuration.info_plist, @configuration.podspec_file]
+        print "Committing #{@configuration.podspec_file} with version #{build_number}"
+        stage_files [@configuration.podspec_file]
         commit_and_push_with_message "Preparing for next pod release #{next_build_number}..."
        
         puts "Done"

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: xcodebuilder
 version: !ruby/object:Gem::Version
-  version: 0.0.18
+  version: 0.0.19
 platform: ruby
 authors:
 - Olivier Larivain
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2013-11-01 00:00:00.000000000 Z
+date: 2014-01-03 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: CFPropertyList