How does a fastlane lane receive parameters, and how do you pass them from the command line?

## Two different things called parameters A Fastfile has two parameter channels, and interviewers listen for whether you keep them apart. - **Lane parameters** are values the *caller* gives the lane. They arrive as one hash, conventionally named `options`, declared as the lane's block parameter. - **Action parameters** are the keyword arguments the lane body hands to an action — `build_app(scheme: "SprayDiary")` for the iOS archive of the orchard spray-diary app, or `upload_to_play_store(track: "internal")` for its Google Play upload. The critical fact is that they are **not connected**. The lane's `options` hash is never forwarded to actions automatically; whatever an action needs, the lane body passes explicitly. A candidate who thinks `fastlane android release track:beta` magically reaches `upload_to_play_store` has the model wrong. ## Declaring and reading them ```ruby platform :android do desc "Ship the orchard spray-diary app to a Google Play track" lane :release do |options| track = options[:track] || "internal" upload_to_play_store(package_name: "com.orchard.spraydiary", track: track) end end ``` Keys are symbols, so the body reads `options[:track]`, not `options.track` and not `options["track"]`. A key the caller omitted is absent rather than an error, so `options[:track]` evaluates to `nil` — which is why the first lines of a parameterised lane are usually defaults. `upload_to_play_store` is the canonical name of the action commonly called `supply`, and it is the Google Play side of this app; naming it canonically is the difference between knowing the tool and knowing its nickname. ## Passing values from the command line The caller appends `key:value` pairs after the lane name: ``` fastlane android release track:beta rollout:0.25 ``` Four behaviours are worth having ready: - The pairs come **after** the lane name; anything before it is read as the platform or the lane itself. - Keys become symbols in the hash, so `track:beta` is read as `options[:track]`. - Values arrive as **strings**. `options[:rollout]` holds `"0.25"`, not a float, and a value meant to be numeric has to be converted inside the lane. - A value containing spaces must be quoted by the shell, and a value containing a colon needs care because the colon is the separator. That string typing is the most common surprise, and it usually shows up as a puzzling failure deep inside an action rather than at the point the parameter was passed. ## Passing values from another lane Invoking a lane from a lane is a plain method call with a hash: ```ruby lane :nightly do release(track: "internal") end ``` Here the values keep their real Ruby types — `release(rollout: 0.25)` delivers a Float, while the same value typed on the command line arrives as a string. A lane that must serve both callers should normalise once, at the top, rather than sprinkling conversions through the body. ## Parameters versus environment variables | | lane parameter | environment variable | |---|---|---| | who sets it | the caller: a CI step's command line, or a calling lane | the environment the process is started in | | good for | what varies per invocation, such as a Google Play track or a release note | credentials and machine-level configuration | | visibility | echoed in the command line, so it lands in build logs | not echoed by the invocation itself | | shape | symbol-keyed hash reachable only inside the lane | process-wide, readable from any action | The visibility row is the one that matters in review: because the command line is printed in most CI logs, a secret passed as a lane parameter is a secret written to a log. Sensitive configuration belongs in the environment, not in the invocation. ## Rules that survive contact with CI 1. **Default every optional parameter explicitly** in the first lines of the lane, so it behaves predictably when a human runs it with no arguments. 2. **Normalise types once.** Convert numeric and boolean-looking parameters at the top, because command-line callers hand you strings and lane callers hand you real objects. 3. **Fail fast on a missing required parameter** with a message naming the parameter, rather than letting an action fail later with an error about something else entirely. 4. **Keep credentials out of parameters**, both because the command line is logged and because a shared runner's process list is not private. 5. **Keep the parameter list short.** A lane taking eight parameters is usually two lanes, and splitting it makes each one easier to re-run after a failure. A parameterised lane is what lets one reviewed definition serve a nightly internal build and a production release: same lane, different values, one place to read.