[match] errSecInternalComponent if not possible to prompt for keychain password

[jakubgs]

Issue Description

Fastlane match when signing the app with a new certificate fails with errSecInternalComponent when run without UI. When run with UI it prompts for password to access the keychain, even if the keychain is unlocked, like so:

Command executed

/usr/bin/codesign --force --sign ${CERT_ID} --preserve-metadata=identifier,entitlements,flags --timestamp=none ${SOME_BINARY_PATH}

Result:

${SOME_BINARY_PATH}: errSecInternalComponent
Command /usr/bin/codesign failed with exit code

Details

This has been an issue across multiple Fastlane versions for over a year at least.
I've been fighting with this for few days in status-im/status-mobile#8745 and here are my findings:

• Fastlane match calls codesign which requires the Keychain file to be unlocked via UI
• This UI unlock can be achieved by clicking Always Allow when prompted for access
  • This allows the future runs without UI to succeed. Necessary for CI hosts.
• Unlocking process is certificate specific and a new certificate requires Always Allow trick again
• The codesign utility does not seem to care if the Keychain file has been unlocked in advance
  • True for both for using security unlock-keychan and creating an unlocked keychain with Fastlane
• Even when using a separate Keychain fastlane still tries to access the default one to import WWDR

Attempted Solutions

I've attempted to create a temporary unlocked keychain as it was suggested in #10589 (comment) and made this:

def with(ctx)
    yield ctx.setup
ensure
    ctx.teardown
end

class Keychain
    attr_accessor :name, :pass
    @@pass = "temppassword"

    def initialize(name)
        # We use epoch time to void clashes with CI builds
        @name = "#{name}_#{Time.now.to_f}.keychain-db"
        @path = "~/Library/Keychains/#{@name}"
        Fastlane::Actions::CreateKeychainAction.run(
            name: @name,
            password: @@pass,
            unlock: true,
            timeout: false,
            # To make Fastlane import WWDR certificate into it.
            default_keychain: true,
        )
    end

    # for use in with()
    def setup; self end
    def teardown; Fastlane::Actions::DeleteKeychainAction.run(name: @name) end
end

Which I tried using like this:

with Keychain.new('adhoc') do |kc|
    match()
    build_ios_app()
end

But the result is the same. Despite the keychain being already unlocked the codesign call still either fails with errSecInternalComponent or prompts for password of UI is available.

Musings

I understand this might not be an issue with Fastlane itself, but rather with the codesign utility. If that is indeed the case than I think it would be prudent to at least publish an explanation of the errSecInternalComponent error under https://docs.fastlane.tools/codesigning/common-issues/. Or maybe even include a warning message in Fastlane that would point to this possible cause. I and probably many others have wasted a lot of time trying to figure out this issue.

The official Apple documentations means literally nothing:
https://developer.apple.com/documentation/security/1542001-security_framework_result_codes/errsecinternalcomponent

Related Issues

• Check Login Password, avoiding prompt #9448
• [HowTo] Avoid keychain prompt to allow access to the private key #10589
• Could not install WWDR certificate #6993
• access keychain problem #12992
• Gym CodeSign error 65 on Bamboo #14859

[fastlane-bot]

It seems like you have not included the output of fastlane env

To make it easier for us help you resolve this issue, please update the issue to include the output of fastlane env 👍

[janpio]

Can you tell us a bit about your environment? (see also what the bot posted)
What would we need to do (exactly) to reproduce this?

[jakubgs]

I don't think the env is that relevant. As I said, I've seen this issue many times over the period of over a year across multiple Fastlane versions, OSX versions, and XCode versions. As far as I can tell this is an XCode - or to be precise codesign - issue that can't be fixed by Fastlane changes.

The most recent instance of this issue is probably #10589.

I think the only thing we can do is at least update the common issues page with explanation of this issue.

But anyway, here's fastlane env from one of our CI hosts:
https://gist.github.com/jakubgs/ce795ab723be96f149719e641db42ed4
And our Fastfile is here:
https://github.com/status-im/status-react/blob/9a0bb7d1/fastlane/Fastfile#L91-L112

And the reproduction is simple:

1. Create certificates and provisioning profiles using fastlane match
2. Attempt to sign your builds with newly created certificates using match and build_ios_app
3. See it fail with errSecInternalComponent if no UI is available, or prompt for keychain pass if it is

[jakubgs]

Oh no bot, you're not closing this one.

[jakubgs]

You're not even human, you can't tell me what to do.

[nikoWah]

Hey I'm facing the same issue.

I've tried to create and unlock the keychains. This issue is making the CI flaky and I don't have any foolproof solution from the documentations provided.

Somehow I think that the unlock feature is not working, as I can see that the keychain database in Keychain Access still has the locked padlock. At this stage, I'm considering to use a static password (instead of a random password) for creating the keychain and click on Always Allow on the UI once.

create_keychain(
  name: KEYCHAIN_NAME,
  password: keychain_password,
  unlock: true,
  timeout: false
)

unlock_keychain(
  path: KEYCHAIN_NAME,
  password: keychain_password,
)

[jakubgs]

BEGONE!

[mrteera]

I've similar issue..

[sakitume]

This just happened to me. My provisioning profiles/certificates expired and I had to nuke them and make new ones (using match). After that happened I experienced the issue with codesign and had the errSecInternalComponent error.

This issue as well as (closed issue) #8745 helped me resolve it. Thank you very much for your hard work and sharing your info @jakubgs.

To (hopefully) resolve this I opened a terminal and executed the fastlane command that my Jenkins server would have run. In this way I was able to see the popup that prompts for a password (see screenshot provided in the "Issue Description" above) and choose "Always Allow".

I kicked off a Jenkins build and am waiting now to see if it succeeds without issue. I'm hoping the codesign phase will be able to unlock my keychain without issue (now). We shall see.

[michallaskowski]

I thought we also have this issue. But after trying to import certificates manually, and setting key partition list it seems it is working. It was just my setup_jenkins and match actions that were misconfigured.
It worked also on a freshly provisioned Mac Mini.

How I tested this manually, your paths and passwords may vary

# import certificate first, just like match does
security import ~/Downloads/development.p12 -k build.keychain -P "" -T /usr/bin/codesign -T /usr/bin/security 1> /dev/null

# list identities for codesigning
security find-identity -v build.keychain

# try to codesign, prompt for password should be visible
codesign --force --sign "id_from_find-identity_goes_here" --timestamp=none `mktemp`

# set-key-partition-list, just as match does
security set-key-partition-list -S apple-tool:,apple:  -k build123 ~/Library/Keychains/build.keychain &>/dev/null

# try to codesign again, this time it should work
codesign --force --sign "id_from_find-identity_goes_here" --timestamp=none `mktemp`

and my before_all lane setup (I use Jenkins, and keychain path and password are in env variables after provisioning)

before_all do |lane|
  setup_jenkins(
    set_code_signing_identity: false,
    keychain_path: ENV["BUILD_KEYCHAIN"],
    keychain_password: ENV["BUILD_KEYCHAIN_PASSWORD"],
    force: true)

  # setup fastlane match with same keychain and password as just unlocked with setup_jenkins
  ENV["MATCH_KEYCHAIN_NAME"] = File.basename(ENV["BUILD_KEYCHAIN"]) if ENV["BUILD_KEYCHAIN"]
  ENV["MATCH_KEYCHAIN_PASSWORD"] = ENV["BUILD_KEYCHAIN_PASSWORD"] if ENV["BUILD_KEYCHAIN_PASSWORD"]

  xcversion(version: ENV["FL_XCODE_VERSION"] || "11.1") # ENV to be able to override version easily for tests
  clear_derived_data
end

After this, match executed before build_ios_app works on a freshly provisioned machine. Tested this also with a fresh certificate and keychain on my MacBook.

MacOs Catalina 10.15, Fastlane 2.140.0, ruby 2.6.3, Xcode 11.1

[fastlane-bot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest fastlane version and check if that solves the issue. Let us know if that works for you by adding a comment 👍

Friendly reminder: contributions are always welcome! Check out CONTRIBUTING.md for more information on how to help with fastlane and feel free to tackle this issue yourself 💪

[ivankrylov]

When importing keys list the apps with granted permissions explicitly
security import ${FILE} -k ${KEYCHAIN} -P ${PASSWORD} -T /usr/bin/codesign -T /usr/bin/productsign

[ciekawy]

I hit this recently setting up headless cicd environment. I've tried number of suggestions so far including:

• unlock_keychain does not seem to work
• creating dedicated keychain with create_keychain - in this case the other error is missing default intermediate Apple WWDR CA (tried to import it manually with no success either).

the only option working is
sh('security unlock-keychain -p "$KEYCHAIN_PASSWORD" login.keychain')

[ivankrylov]

By default headful macOSs already have login.keychain for each user and therefore creating one is no-op. The fact that it helped means that this keychain was missing and therefore creating one is the right thing.

[jakubgs]

By default headful macOSs already have login.keychain for each user and therefore creating one is no-op.

That doesn't make sense. Keychain is just a file, you can have and use as many as you want.

[palmerc]

And in case I wasn't clear - this needs to be on the Gitlab-CI runner

[zelanastasia]

I pretty sure that i have it all, as i know xcode automatically install all of them. But i see they in certification center

What do you mean this needs to be on the Gitlab-CI runner? Runner runs on this macmini and use all of it.

[palmerc]

This is a MacMini Gitlab CI Runner:

[palmerc]

In Russian Система

[zelanastasia]

This is a MacMini Gitlab CI Runner:

I see, also found some answer that explain your questions https://stackoverflow.com/questions/69464483/codesign-fails-during-export-using-a-launchd-runner
I will try it, thnks

[sebsto]

I gave it a fresh look today. It works after a bit of manual configuration of the keychains. This is what Fastlane Match should do for us.
Here are my findings.
Fastlane 2.210

First, Fastlane Match does not work with custom keychain. Using keychain_name("dev-match") causes a ton of errors. It looks like Fastlane Match relies on login.keychain and it is hardcoded at many places.

Second, I admit I have to use the login keychain.

I started with a fresh System.keychain

KEYCHAIN_PASSWORD=Passw0rd
KEYCHAIN_NAME=login.keychain
SYSTEM_KEYCHAIN=/Library/Keychains/System.keychain
AUTHORISATION=(-T /usr/bin/security -T /usr/bin/codesign -T /usr/bin/xcodebuild)

sudo security delete-keychain "${SYSTEM_KEYCHAIN}" 
sudo security create-keychain -p "${KEYCHAIN_PASSWORD}" "${SYSTEM_KEYCHAIN}"
sudo security list-keychains -s "${SYSTEM_KEYCHAIN}"
curl -s -o $CERTIFICATES_DIR/AppleWWDRCAG3.cer https://www.apple.com/certificateauthority/AppleWWDRCAG3.cer
sudo security import $CERTIFICATES_DIR/AppleWWDRCAG3.cer -t cert -k "${SYSTEM_KEYCHAIN}" "${AUTHORISATION[@]}"

I let Fastlane Match import the signing key to the login keychain. I ensure the login keychain is NOT locked and will NOT timeout.

security unlock-keychain -p "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"
security set-keychain-settings "${KEYCHAIN_NAME}" # remove the lock timeout

Be sure the search list is correct

sudo security list-keychains -s $HOME/Library/Keychains/login.keychain-db /Library/Keychains/System.keychain

Then verify the root certificate and your sign key are present

security find-certificate -c "Apple Worldwide Developer Relations Certification Authority"  /Library/Keychains/System.keychain

security find-identity -v -p codesigning

With the above setup - a fastlane build command works for me from a SSH session

[palmerc]

Gitlab CI is where I have had issues and this is directly a result of running it as a LaunchDaemon. I definitely use custom keychains and dynamically created and destroyed ones at that. The central issue is that gitlab-runner as a launch daemon is running in a system context and cannot / will-not see the intermediates if they aren't in the System keychain. Furthermore, it is increasingly difficult to manage certificates across 20+ builders, because things like import are difficult to script. I simplified my life by creating an MDM profile and attaching the certificates.

[WoodyWoodsta]

Can we continue this discussion somewhere else please.

…

On Fri, 7 Oct 2022 at 1:22 pm, Anastasia ***@***.***> wrote: I pretty sure that i have it all, as i know xcode automatically install all of them. But i see they in certification center [image: image] <https://user-images.githubusercontent.com/60486232/194551981-c560cfad-3644-4b2d-b976-639d4735b9a4.png> What do you mean this needs to be on the Gitlab-CI runner? Runner runs on this macmini and use all of it. — Reply to this email directly, view it on GitHub <#15185 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB7CSCDX4CNQK5YFQXASLR3WCAIYNANCNFSM4IL7Z3JA> . You are receiving this because you commented.Message ID: ***@***.***>

[paulz]

what helped us to to add this step to the build script before running fastlane:

security unlock-keychain -p *** login.keychain

[CristianMG]

Use pm2 and be free!!!

[CristianMG]

Ok, I have to explain better, for any reason, the daemons can't access user keychain only system keychain, we install pm2 to start task in mac mini at start, task is able to access keychain without problem.
https://pm2.keymetrics.io/
Maybe can be useful for some people

[hwo411]

I seem to have a solution. Ran into this problem today while setting up the new Mac for CI.

When you install the certificate first time with match, you just need to supply keychain_password (e.g., as MATCH_KEYCHAIN_PASSWORD env variable). fastlane seems to do all the necessary actions to give codesign access to keychain, but only if you supply password and when you install the certificate.

Code that I inspected:

fastlane/match/lib/match/utils.rb

Line 9 in b4263a2

FastlaneCore::KeychainImporter.import_file(item_path, keychain_path, keychain_password: password, output: FastlaneCore::Globals.verbose?)

fastlane/fastlane_core/lib/fastlane_core/keychain_importer.rb

Line 41 in b4263a2

def self.set_partition_list(path, keychain_path, keychain_password: nil, output: FastlaneCore::Globals.verbose?)

+SO reference
https://stackoverflow.com/questions/54463588/allow-certain-apps-to-access-the-keychain-using-command-line

I see a similar answer above: #15185 (comment)

But for me with a fresh install (I used tart VM to test setup) it worked just with what I mentioned in this comment.

Hope that it helps.

[shalins]

Do we have to use match for the above workarounds to work? I'm using build_app (https://docs.fastlane.tools/actions/build_app/), which also seems to use /usr/bin/codesign /usr/bin/codesign --force --sign ... --keychain=/Users/username/Library/Keychains/fastlane.keychain-db and causes a errSecInternalComponent.

Here is my Fastfile:

		create_keychain(
			path: "/Users/username/Library/Keychains/fastlane.keychain-db",
			password: 'mySecurePassword',
			default_keychain: true,
			unlock: true,
			timeout: 3000,
			lock_when_sleeps: false,
			add_to_search_list: true
		)
        build_app(
			workspace: "MyApp.xcworkspace", 
			scheme: "MyApp",
			xcargs: "OTHER_CODE_SIGN_FLAGS=--keychain=\"/Users/username/Library/Keychains/fastlane.keychain-db\"",
			export_options: {
				provisioningProfiles: {
					"com.myapp.myapp-nightly" => "MyApp_Nightly",
				}
			}
		)
        upload_to_testflight

I've tried adding:

		unlock_keychain( 
			path: "/Users/username/Library/Keychains/fastlane.keychain-db",
			password: "mySecurePassword",
			add_to_search_list: true, 
			set_default: true
		)

I've tried variants of that too: including using just path: fastlane.keychain and path: fastlane.keychain-db, or using an environment variable for the password.

I've also tried adding the following:

    sh("security unlock-keychain -p mySecurePassword /Users/username/Library/Keychains/fastlane.keychain-db")
	sh("security import /Users/username/ios/fastlane/certificates.p12 -k /Users/username/Library/Keychains/fastlane.keychain-db -P \"\" -T /usr/bin/codesign -A")
	sh("security -v set-keychain-settings -lut 7200 -l ~/Library/Keychains/fastlane.keychain-db")
	sh("security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k mySecurePassword /Users/username/Library/Keychains/fastlane.keychain-db")

None of the workarounds mentioned above seem to work for me, I'm not even sure what to try at this point.

[tylermilner]

I stumbled upon this thread after dealing with some code signing issues on my self-hosted GitHub Actions runner. In the interest of helping anyone else that might encounter this issue, here's the story of how I solved it in my case:

I was using a fresh install of macOS 12.6.3 on a 13" MacBook Pro mid-2010 (patched using OCLP) and Xcode 14.2, but was always receiving the UI prompt to enter the login keychain password even though I was creating and using a temporary keychain in my Fastfile:

This would cause the build to hang at the codesign step of gym and eventually get killed by GitHub's 6 hour build timeout.

The only thing that worked to bypass the keychain prompt was setting the value of default_keychain to true when creating the temporary keychain in my Fastfile:

create_keychain(
  name: keychain_name,
  password: keychain_password,
  default_keychain: true, # Needs to be set to true to prevent keychain prompt on self-hosted runner
  unlock: true,
  timeout: 3600 # 1 hour
)

While this did work, it was not an ideal solution since it messes with global keychain state. On a CI, it's not a huge deal, but I didn't really trust it to continue to keep working reliably. Also, it caused my keychains to get switched around when running locally on my development machine, which was a big pain if I forgot to manually go back and set my login keychain to the default. I could have worked around this by using is_ci in my Fastfile, but I wanted to avoid that if possible so that I could have my build steps mirrored 100% when running Fastlane locally vs on CI.

Eventually, I got tired of trying other workarounds and suggestions so I decided to start fresh. I reinstalled macOS, this time macOS 12.6.4 (again using OCLP to get it installed on my older MacBook) and again using Xcode 14.2. However, now I was getting a problem with the increment_build_number step of my Fastfile, before even getting to the gym command. I believe the error was something like Failed to locate 'agvtool', requesting installation of command line developer tools. and this time it was the prompt to install the command line tools that was popping up for every build instead of the keychain prompt. How frustrating!

I did some more investigation and was unable to recreate the issues when using self-hosted runners installed in VMs using UTM on my M2 Macbook Pro development machine:

• macOS 12.6 VM (using UTM) + Xcode 14.2 - ✅
• macOS 13.3 VM (using UTM) + Xcode 14.2 - ✅

Using a VM on my development machine isn't a terrible option for a self-hosted runner, but I didn't want the hassle of needing to remember to start it up when I wanted to get builds processed and shut it down when I wanted to get max battery life. Also, UTM is still somewhat buggy so dealing with it on a daily basis would have been a pain.

Luckily Open Core Legacy Patcher 0.6.2 had just come out, which brought macOS 13 support to several legacy Macs, my ancient MacBookPro7,1 included. I went through the process to install macOS 13.3 on my 2010 MacBook Pro 13" using OCLP and by now Xcode 14.3 had been released so I used that instead of Xcode 14.2. Without any extra special steps or workarounds, everything was now working perfectly! No more "enter password for login keychain" prompts or weird errors with agvtool.

So it seems like some of these issues we're encountering could be due to the versions of macOS and/or Xcode that are being used. In my case, it only started working for me on the latest macOS 13.3 and Xcode 14.3 and I pray that it will continue to work reliably for me. 🙏

I should also mention that I was using Fastlane 2.212.1 throughout the whole process, with my project setup to properly lock my build and ruby dependencies between my development machine and CI using Gemfile.lock, .ruby-version, etc.

And here is the contents of my Fastfile in case it helps anyone else. As you can see, I no longer need to set default_keychain: true, which means there is also no need to introduce Fastfile logic branching when running on my development machine vs my Mac CI.

default_platform(:ios)

before_all do |lane, options|
  # Make sure fastlane is being executing using 'bundle exec' prefix
  ensure_bundle_exec()
end

platform :ios do
  # Variables available to all lanes
  ci_build_number = ENV["BUILD_NUMBER"] ? ENV["BUILD_NUMBER"] : "1" # Defaults to build number "1"
  build_directory = ENV["BUILD_DIRECTORY"] ? ENV["BUILD_DIRECTORY"] : ".build" # Defaults to ".build" directory for build artifacts
  derived_data_path = "#{build_directory}/DerivedData"
  scheme = "MyAppScheme"
  target = scheme
  qa_build_type = "adhoc"
  qa_build_configuration = "QA"

  desc "Create QA build"
  lane :buildQA do
    # Make sure the required environment variables are present
    ensure_env_vars(
      env_vars: [
        "MATCH_PASSWORD", # Decrypts the match repository
        "MATCH_GIT_BASIC_AUTHORIZATION" # Base64 encoded GitHub PAT to access the match repository
      ]
    )

    # Create a keychain for match to use when installing signing certificates
    keychain_name = "fastlane-temp-#{SecureRandom.hex(8)}.keychain-db"
    keychain_password = SecureRandom.hex(8)
    
    create_keychain(
      name: keychain_name,
      password: keychain_password,
      default_keychain: false,
      unlock: true,
      timeout: 3600 # 1 hour
    )

    # Catch any errors from this point forward so that the temporary keychain can be cleaned up
    begin
      # Run match to install signing certificates and provisioning profiles
      match(
        type: qa_build_type,
        readonly: true,
        keychain_name: keychain_name,
        keychain_password: keychain_password,
        verbose: true
      )

      # Set the build number
      version_number = get_version_number(target: target)
      build_number = ci_build_number
      increment_build_number(
        build_number: build_number
      )

      # Build app
      output_name = "#{scheme}_#{qa_build_configuration}_#{version_number}_#{build_number}"
      gym(
        derived_data_path: derived_data_path,
        configuration: qa_build_configuration,
        scheme: scheme,
        clean: true,
        output_directory: build_directory,
        output_name: output_name,
        archive_path: "#{build_directory}/#{output_name}",
        verbose: true
      )
    ensure
      # Always clean up the temporary keychain
      delete_keychain(
        name: keychain_name
      )
    end
  end
end

[ladislas]

I faced a similar issue myself running fastlane gym on a macOS self-hosted Github Actions runner.

Running the process manually on the runner was working without any issues. Running the process through ssh or Screen Sharing.app was working as well.

On Github Actions was failing.

I tried all the answers above and all the combinations possible, without any success.

Then I stumbled upon those:

• https://developer.apple.com/forums/thread/666107
• https://stackoverflow.com/a/40039594/2205264

And the proposed solution actually works! 🚀 🎉

system('security', 'set-key-partition-list', '-S', 'apple-tool:,apple:', '-s', '-k', '{{ keychain password }}', '{{ keychain name }}')

Reverse looking into it here, the solution had already been posted in #14040 by @Katsz on March 2019

#14040 (comment)

Hope this helps :)

[sebsto]

Thank you @ladislas This is indeed what I do when using bash script. Any example on how / where to use this command with fastlane ?

[Katsz]

@sebsto

This is indeed what I do when using bash script

If I understand correctly fastlane match will try to unlock keychain for you, but there is more:

I came across an issue with some Mac devices (but not others, smh) running Monterey and up where the login keychain was invisible when running a CI process via launchd.
Therefore you won't be able to unlock it with security set-key-partition-list

If so, you can add an undocumented key to your .plist

<key>SessionCreate</key>
<true/>

Any example on how / where to use this command with fastlane ?

fastlane has sh action

[paulz]

If so, you can add an undocumented key to your .plist

@Katsz what plist file name you mean?

Another thing that we do on self hosted runner is to allow access to keychain items:

by selecting "Always allow access by these applications:"

[Katsz]

@Katsz what plist file name you mean?

I discussed the launchd daemon used to start your CI. While I'm not familiar with setting up self-hosted Github actions, it probably uses launchd to start itself after a reboot. If that's the case, you can find Github's daemon in a .plist file named actions.runner.plist (although I'm not entirely certain) under one of these folders:

/Library/LaunchDaemons
/Library/LaunchAgents
~/Library/LaunchAgents

[sebsto]

@Katsz use launchd with a LaunchDaemons only.
LaunchAgents are launches when a user logs in. In the case of a CICD machine, you want the agent to start when the machine starts, this is the role of a LaunchDameon.

Here is a plist file that works for me: GitHub, GitLab, CircleCI
And here is a bash shell script to prepare the keychain that also works for me:

[ladislas]

Thank you @ladislas This is indeed what I do when using bash script. Any example on how / where to use this command with fastlane ?

In our release lane, we have the following:

if is_ci
  app_store_connect_api_key(
    key_id: ENV.fetch('APP_STORE_CONNECT_API_KEY_ID', nil),
    issuer_id: ENV.fetch('APP_STORE_CONNECT_ISSUER_ID', nil),
    key_content: ENV.fetch('APP_STORE_CONNECT_API_KEY_CONTENT', nil)
  )

  unlock_keychain(
    path: 'io.leka.fastlane.keychain',
    password: ENV.fetch('FASTLANE_KEYCHAIN_PASSWORD', nil)
  )
  system('security', 'set-key-partition-list', '-S', 'apple-tool:,apple:', '-s', '-k', ENV.fetch('FASTLANE_KEYCHAIN_PASSWORD', nil), 'io.leka.fastlane.keychain')
end

[Katsz]

@Katsz use launchd with a LaunchDaemons only.

For sure, but if you follow Github's tutorial it will be installed as LaunchAgent if I recall correctly.

[sebsto]

@Katsz You are correct, and this is a mistake in GitHub and GitLab documentation.

LaunchAgents are for apps that start at login, i.e. when there is a graphical session started on the machine. It works well for machines sitting on or under your desk, or in a closet not too far away.

I am trying to industrialize build pipelines in the cloud. On cloud machines, there is no keyboard and screen attached. You may connect through VNC, but this is not recommended. The recommendation is to never connect to the machine, except for initial installation (and even ...) and take a disk snapshot.
In this use-case, when no user are ever connecting to the graphical session, LaunchAgents are pointless. You need a LaunchDaemons.

LaunchDaemons works well for CICD agents. As someone mentioned, you must just ensure to pass the SessionCreate parameter in the plist file.

[palmerc]

This of course is all becoming much harder because of Apple taking away the ability to remotely administer machines, pushing us into MDM solutions. Although, I am interested in toying around with Dockerized OSX and I'm actively working at building on Linux.

[rwong2888]

I am using @sebsto's solution

However, now I am finding I need to restart every so often and rerun on my mac2.metal ec2 instance.

sw_vers
ProductName:		macOS
ProductVersion:		13.4.1
BuildVersion:		22F82

I am doing fastlane tests with one scheme, and fastlane build and testflight with another scheme. Not sure if that is causing the issue, or if there is something new in the later OS version.

Any help would be greatly appreciated.