[bjorkert]

fastlane is pinned in the Gemfile, but it still prints "Please update using bundle update fastlane" and the full changelog at the end of every run whenever a newer release exists. When a build fails, that notice comes after the real error and is easy to mistake for the cause. FASTLANE_SKIP_UPDATE_CHECK turns off the check and the notice. The pin is still bumped by hand when a newer fastlane is needed.

[marionbarker]

Claude review

This PR turns off fastlane’s update notice for the build workflow’s own fastlane steps, but not where most failures happen.

1. Reusable workflows don’t pick up the setting. A workflow’s top-level env: doesn’t carry over to workflows it calls with uses:. So when “Build LoopFollow” calls create_certs.yml, which then calls validate_secrets.yml, those fastlane runs still check for updates. Those are the steps that usually fail, from a bad match password or certificate problems, so the notice still shows up after the real error.
2. The other fastlane workflows are left out. add_identifiers.yml, create_certs.yml and validate_secrets.yml can also be run by hand, and the setup docs tell users to do that. The fix is one line, FASTLANE_SKIP_UPDATE_CHECK: true, in each file’s top-level env:. Setting it in the Fastfile wouldn’t help, because fastlane starts the update check before it loads the Fastfile.

[bjorkert]

Good catch. The env var is now set at the top level of all four workflows (build, create_certs, validate_secrets and add_identifiers), so it also applies when they are called as reusable workflows or run on their own. I ran Add Identifiers on my fork, which also runs validate_secrets as a called workflow, and the update notice no longer shows up in any job. An earlier build on the same fork printed it in both the certificate check and the build step.

[marionbarker]

Claude is happy now.
Approved by test - ran each action, all succeeded.