fastlane: Cannot get lane shared values for ios bundleid

Hey guys 👋 I will jump on it and see what I can do, although I am not very familiar with match and sigh code, so it might take a bit 🙂 🙇

I am glad proposed solution did work 💪 at the same time I agree - it does not look pretty and would be great to improve it.

One solution might be adding ENV variable ENV["MATCH_INSTALLED_PROFILE_PATH"] to the match lane. It is what we basically do in runner.rb (ENV it is named differently though):

https://github.com/fastlane/fastlane/blob/c3e1d4e0a956c655da1dc037f8c34d120707aef0/match/lib/match/runner.rb#L298-L301

The question is if we should add the new ENV variable? I believe it will be clear once we figure out https://github.com/fastlane/fastlane/issues/14255 issue 👍

WDYT guys?

Then I definitely misunderstood your tone

Internet and non-verbal communication… am I right? 😃 @janpio

This issue here actually triggered a bigger investigation at #14255 into how ENV vars and lane_context are intended to be used.

That’s a great question and something that definitely got confusing for me while studying the documentation

Then I definitely misunderstood your tone - happens sometimes after reading >50 issues from sometimes angry people from the internet 😃 Sorry 🙇‍♀️

Let’s keep this open, maybe @mollyIV (can think of and) wants to implement a better solution.

This issue here actually triggered a bigger investigation at https://github.com/fastlane/fastlane/issues/14255 into how ENV vars and lane_context are intended to be used. Murky area as we found out, so we invest a bit of time to maybe be able to clean that up.

It does, however just after installing them, it clears the storage by calling

https://github.com/fastlane/fastlane/blob/69c04c5093175ca646e3b91c42107f239bfb5cd9/match/lib/match/runner.rb#L123

Maybe @hydraSlav could simply use an environment variable in that case? According to the code:

https://github.com/fastlane/fastlane/blob/69c04c5093175ca646e3b91c42107f239bfb5cd9/match/lib/match/runner.rb#L290-L293

https://github.com/fastlane/fastlane/blob/69c04c5093175ca646e3b91c42107f239bfb5cd9/match/lib/match/utils.rb#L31

The convention name is sigh_applicationId_profile-path.

The difference here is that match stores the profiles on a remote location like Git or Google Cloud and sigh stores the profiles locally. That’s why we can provide a provisioning profile path after calling a sigh, but not for match.

@janpio @mollyIV

match does store profiles (and certs) in a remote repo, however it also installs them locally into the default location same as what Xcode uses, i.e /Users/username/Library/MobileDevice/Provisioning Profiles/

This below is from running match(type: "adhoc")

13:05:54 INFO [2019-02-15 13:05:54.86]: Installing provisioning profile...
13:05:55 WARN [2019-02-15 13:05:55.32]: Setting environment variable 'sigh_com.blah_adhoc' to '97c39a3e-ZZZ-111-222'
13:05:55 WARN [2019-02-15 13:05:55.32]: Setting environment variable 'sigh_com.blah_adhoc_team-id' to 'ZZZZZ11111'
13:05:55 WARN [2019-02-15 13:05:55.32]: Setting environment variable 'sigh_com.blah_adhoc_profile-name' to 'match AdHoc com.blah'
13:05:55 WARN [2019-02-15 13:05:55.32]: Setting environment variable 'sigh_com.blah_adhoc_profile-path' to '/Users/username/Library/MobileDevice/Provisioning Profiles/97c39a3e-ZZZ-111-222.mobileprovision'

Hm, that is very much possible @mollyIV - if match only leaves it in the keychain, it will indeed be difficult. (Semi related: But as match should work on Windows as well, sooner or later there has to be an export option (if there is not already) anyway.)

Maybe it is time to take a step back and think about how to solve @hydraSlav 's original problem another way then:

I need the profile_path for the following: automatic_code_signing( use_automatic_signing: false, team_id: "ZZZZZ", code_sign_identity: "iPhone Developer", profile_name: profile_path_here )

The one way of looking at it is if one lane executes another under the hood, it should expose the same shared hash values. WDYT?

Yep, that is a valid justification. match also already does this, but only partially.

Do you know what’s the best way to test the changes in those two lanes? Is it adding new unit tests? Or it’s just running and debugging, because unit testing might be quite hard in those cases?

Have a look at the unit tests that exist - if you can put new stuff in there, great. In this specific case I think that those ENV vars and shared values are probably not tested for, so the best way to test for them will be to create a lane that reproduces the problem and checks if the value is available after your changes.

I’d vote for the solution where we would put all Actions.lane_context[SharedValues::...] value settings to Sigh::Manager.start static method 👍 Although we’d need to investigate how many different components are calling Sigh::Manager.start as well, and what impact it has.

Yep, sounds good. If it’s not super easy, feel free to copy paste the “set the value” lines over from one to another. No reason to invest to much time here.

So just go ahead @mollyIV! 🚀

I agree with your first and second point @hydraSlav, but the third suggesting an option is not necessary here. Keep it simple.

Before I start implementing the changes, gonna ask a few follow-up questions 😊

1. Are there any conventions / rules when we should set the values for shared hash?

According to Lane Context documentation:

The different actions can communicate with each other using a shared hash.

Wondering whether match should expose the same shared hash values that sigh does 🤔 The one way of looking at it is if one lane executes another under the hood, it should expose the same shared hash values. WDYT?

2. Testing changes in match and sigh lanes

Do you know what’s the best way to test the changes in those two lanes? Is it adding new unit tests? Or it’s just running and debugging, because unit testing might be quite hard in those cases?

3. Implementation details I’d vote for the solution where we would put all Actions.lane_context[SharedValues::...] value settings to Sigh::Manager.start static method 👍 Although we’d need to investigate how many different components are calling Sigh::Manager.start as well, and what impact it has.

WDYT? 🙇

cc: @janpio , @hydraSlav

So you didn’t learn a new thing for a week now - time to start 😉

Of course it’s fine if you don’t want to jump in, please allow us a bit of time to take care of this. I added the you can do this tag to the issue, maybe someone else notices and creates a PR.