build: upgrade to fastlane 2.228.0

[iBotPeaches]

The problem

🔑 Fastlane builds are failing during "Validate Documentation" step. Its failing because the fastlane installed version (2.220.0) is older than the assertions.

 [00:49:33]: Error found in code sample:
setup_ci(
  provider: "circleci",
  timeout: 0,
  keychain_name: "custom_keychain_name"
)
Unknown parameter 'keychain_name' for action 'setup_ci'

#######################################################################
# fastlane 2.228.0 is available. You are on 2.220.0.
# You should use the latest version.
# Please update using `bundle update fastlane`.
#######################################################################

This parameter was added in 2.227.0 and all the other errors are a similar story. The docs repo must be aligned with the fastlane version (to some degree).

There hasn't been a documentation update till a few days ago for v2.228.0, the last version was done by Josh for v2.220.0.

v2.220.0 ran the script to run bundle update, the v2.228.0 release did not. I do not know why the other releases between 220 and 228 were skipped, but all this led to the CI for fastlane failing. There might be a reason why this has not been done, but I don't know it.

The Solution

This issues a bundle update to bring the fastlane version to 2.228 which should get us closer to a green fastlane pipeline.

[iBotPeaches]

cc @rogerluan - To help me learn here. When you did the automation for last release did you intentionally skip the bundle update? Or maybe the script was bugged? Trying to figure out why release v2.220 did a bundle update, but not v2.228.0.

[rogerluan]

cc @rogerluan - To help me learn here. When you did the automation for last release did you intentionally skip the bundle update? Or maybe the script was bugged? Trying to figure out why release v2.220 did a bundle update, but not v2.228.0.

I didn't - this may be a bug. I'll keep an eye to see if it happens again on the next release 🙏

[rogerluan]

Thanks for fixing this! 🙏

[iBotPeaches]

I didn't - this may be a bug. I'll keep an eye to see if it happens again on the next release 🙏

Ahh too bad those logs expired on last release. I'll check next time there is a release as well to help fix. Trying to get all projects green and work on the CI pipelines.

[janbrasna]

"I do not know why the other releases between 220 and 228 were skipped"

It's a long~ish read, but fastlane/fastlane#22167 ~ fastlane/fastlane#22090 (comment)

Thanks for all this work.

[iBotPeaches]

It's a long~ish read, but fastlane/fastlane#22167 ~ fastlane/fastlane#22090 (comment)

Thanks for all this work.

AH so in the move to GH automation, the automation with docs pipeline wasn't wired up properly. Somehow in 228 it was run manually (or fixed?) which showed its lack of usage for a few release cycles isn't quite perfect with the releases that have to work hand in hand between docs/main.

I need to go dig some history to see what should be wired up into where.

[janbrasna]

"in the move to GH automation, the automation with docs pipeline wasn't wired up properly"

In the move to triggering releases via GitHub "Release" functionality, instead of just triggering tags or generally bumping from cli/lanes.

Before, bumps were run in :release lane, that seemed to be the only place to run :update_docs — and there's not an equivalent in :create_github_release IIUC.

The start of the rough edges is probably here:

• [ci] automate GitHub Release creation with attached Gem fastlane#22090
• [ci] creates a bump PR from a manual action trigger fastlane#22077
• [ci] Initial attempt at automating bump on GitHub Actions fastlane#22075
• [ci] fix tag action workflow fastlane#22082

[iBotPeaches]

The start of the rough edges is probably here:

* [[ci] automate GitHub Release creation with attached Gem fastlane#22090](https://github.com/fastlane/fastlane/pull/22090)

* [[ci] creates a bump PR from a manual action trigger fastlane#22077](https://github.com/fastlane/fastlane/pull/22077)

* [[ci] Initial attempt at automating bump on GitHub Actions fastlane#22075](https://github.com/fastlane/fastlane/pull/22075)

* [[ci] fix tag action workflow fastlane#22082](https://github.com/fastlane/fastlane/pull/22082)

Thanks so best I can tell releases were always manual triggered locally, but logic in codebase automated a chunk of it. It however, was not truly automated via machines.

The move to GH changed that, but it seems it was a rocky transition with a few workflow files split and abandoned and never getting true parity with the local execution of release lane process. update_docs lane is a bit rocky as well, since it requires Ruby Gems authentication due to leveraging a similar pre-check process as the release.

It also runs a generic bundle update which is killer for a CI pipeline to be live updating dependencies prior to a commit and assumes Ruby/Bundler will be configured in a certain way. Especially with how old support is (the docker images run on Ruby 2.7) you probably have a different method of running Ruby dependencies than a system call of "bundle update".

Saying that, update_docs has a ton of options to skip ruby, and more. So the tight coupling between fastlane/fastlane being responsible for cloning fastlane/docs and standing it up to run some commands is part of this challenge.

My problem at the moment is all build logs of the last releases on GH have expired so I cannot confirm my assumptions till another fastlane release goes out and I can peek logs. I'm confident at least to remove unused jobs and fix bugged ones - to have a smaller mind model to process - fastlane/fastlane#29728

Another confident thing I could make on docs is standardizing gem install location - #1289