Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve how App and Ipa instances detect the Calabash server version #379

Merged
merged 18 commits into from
Feb 3, 2016

Conversation

jmoody
Copy link
Contributor

@jmoody jmoody commented Jan 29, 2016

Motivation

The previous implementation (thanks @ark-konopacki) had a couple of problems:

  1. It did not detect calabash dylibs - the load-dylib-at-runtime case
  2. It did not correctly extract pre release versions

This PR is a bit long and I am sorry for that. I will annotate the changes with notes to help the reviewer.

Related to (private links):

@@ -14,6 +14,20 @@ class App
# @return [RunLoop::App] A instance of App with a path.
def initialize(app_bundle_path)
@path = File.expand_path(app_bundle_path)

if !App.valid?(app_bundle_path)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Immediately raise an error if the app bundle is invalid. This avoids having to check in each instance method.

@jmoody jmoody modified the milestones: 2.0.5, 2.0.6 Jan 29, 2016
@jmoody
Copy link
Contributor Author

jmoody commented Jan 29, 2016

No hurry on this @sapieneptus. It does not have to be part of the next release.

def payload_dir
@payload_dir ||= lambda {
@payload_dir ||= lambda do
FileUtils.cp(path, tmpdir)
zip_path = File.join(tmpdir, File.basename(path))
Dir.chdir(tmpdir) do
system('unzip', *['-q', zip_path])

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought we were supposed to use ditto ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this operation we are copying a zip file (.ipa) to a temp location.

It is safe, I think, to copy with cp. Who knows, maybe FileUtils.cp is implemented with ditto on MacOS.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify, we should use ditto when copying .app (app bundles) directories. I don't think we need to use ditto when copying archive files because the resource forks are included in the archive.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was talking about the unzip, not the cp

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

E.g., for resigning we do:

    // NOTE: To correctly preserve MACOS metadata we must use ditto instead of zip.
    // Failing to do so can make codesign bail out with some very exotic
    // error messages in some rare cases.
    ShellOrDie("ditto", "-x", "-k", "--sequesterRsrc", filepath, tmpDir)

Perhaps it's not relevant here, but I thought it was just generally safer

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(>_O) Of course you were.

I will fix this.

plist?(file) ||
lproj_asset?(file) ||
code_signing_asset?(file) ||
core_data_asset?(file)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jmoody Why not use a whitelist approach instead? Files that need to be checked for calabash linkage should be just the main app binary and any dylibs

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whitelist

I thought about pretty seriously. I am tempted to use a whitelist.

I was thinking about extensions and a future where we would automate those as well - but the same whitelist rules would apply.

I think I will change the approach now to use whitelist.

@sapieneptus
Copy link

@jmoody The comments I have made are non-blocking. I don't think cp vs ditto will cause any problems here (at least I don't have any indication that they would cause problems outside of a codesigning context). I do think it may be worth considering a whitelist approach for skip_executable_check, but it seems you've already gotten substantial performance gains.

I don't have enough context to say whether or not this will aversely impact the rest of RunLoop, but I don't see anything obviously wrong with the PR and the tests are passing. So with that in mind, I would say it's good to go.

@jmoody jmoody assigned jmoody and unassigned sapieneptus Feb 1, 2016
@jmoody
Copy link
Contributor Author

jmoody commented Feb 3, 2016

@sapieneptus

I thought more about using a whitelist and had a brief conversation with Simon.

I don't think we actually can make a whitelist that would cover all cases.

@jmoody
Copy link
Contributor Author

jmoody commented Feb 3, 2016

Grr. Travis is failing because it can't install ruby 2.1.7.

Merging. Will deal with this failure if it occurs on develop.

jmoody added a commit that referenced this pull request Feb 3, 2016
…version-take-2

Improve how App and Ipa instances detect the Calabash server version
@jmoody jmoody merged commit f5d0367 into develop Feb 3, 2016
@jmoody jmoody deleted the feature/detect-calabash-server-version-take-2 branch February 3, 2016 16:59
@sapieneptus
Copy link

@jmoody Sorry to keep going back and forth on this, but I thought we agreed that whitelisting by executable binary would be sufficient? I'm pretty sure we can use file and regex for /Mach-O * executable/

@jmoody
Copy link
Contributor Author

jmoody commented Feb 4, 2016

back and forth

No worries. Makes the code better. +1

whitelist

I thought you were arguing for a whitelist with these rules:

  1. test the CFBundleExcutable (the app binary)
  2. any dylib

file

I looked at file and was not convinced it was the right tool. otool seems definitive.

executable binary

This is the behavior. A list of executables is created and strings is call on the elements of that list to detect the Calabash iOS server version.

@jmoody jmoody mentioned this pull request Feb 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants