this bit I don't love: I had to make it a parameter of base job rather than the concrete deploy purchase tester job.

It doesn't actually affect anything other than the fact that all jobs get this param now. Maybe that's deceiving in that if you run the other deploy stuff with dry_run: true, it's not an actual dry run, and that's a bit concerning.

But I couldn't find a better way of keeping it specific to the job: the thing is that we inherit all the stuff from the base job, and that includes parameters. If I declare it again, it breaks the config.

I could also not inherit from base job and just copy/paste all of its things, but I feel like that's worse than what we had before.

I'm open to other ideas, especially since overall this doesn't entirely feel better to me than having two almost identical jobs. I'm worried that a future dev could think that dry_run on all jobs actually means dry run.

Right, I certainly don't love it either and it can be confusing... Not aware of any other options off the top of my head, so I agree with you we might as well leave it as 2 separate jobs.

I think the base job should actually be an executor not an alias:

executors:
  macos-executor:
    parameters:
      xcode_version:
        type: string
        default: '15.3'
      install_swiftlint:
        type: boolean
        default: true
    macos:
      xcode: << parameters.xcode_version >>
    resource_class: macos.m1.medium.gen1
    environment:
      CIRCLECI_TESTS_GENERATE_SNAPSHOTS: << pipeline.parameters.generate_snapshots >>
      CIRCLECI_TESTS_GENERATE_REVENUECAT_UI_SNAPSHOTS: << pipeline.parameters.generate_revenuecatui_snapshots >>
    working_directory: ~/purchases-ios
    shell: /bin/bash --login -o pipefail

We can keep the alias so we don't have to update all jobs now:

aliases:
  base-job: &base-job
    executor:
      name: macos-executor

Then you can have custom parameters for the job

 deploy-purchase-tester:
    executor:
      name: macos-executor
    parameters:
      dry_run:
        type: boolean
        default: false

I haven't tested it but the config passes CircleCI validation and it matches CircleCI's documentation

ohh that's great, I'll give it a shot. Thanks!

Updated with this approach, looks soooo much better! I hope that it does work. If it does I'll do another follow-up to remove the old base job alias

I ran into some issues with failing tests when mixing and matching this approach and the alias... And this approach is just better than the alias, so I went ahead and replaced it altogether

entirely replaces the base job alias with the executor

Much better!

This was honestly a pretty deceiving one - you would have to re-define it as a param, but then also remember to pass it in, which was kinda weird (you'll see what I mean in other comments).
And it's not super useful, so I removed it so we can use it at the job level instead

regular usage is just so much cleaner

Yea, I think it's not a bad idea to use aliases only sparingly, because of the inflexibility they often introduce.

these jobs didn't actually install swiftlint, even if you pass in true here, since that happens if you call install dependencies, so you could have thought that it should work and gone crazy trying to figure it out

again, this just looks nicer, and you don't have to redefine the parameter every time including the type

here I just use the param directly, I feel like this is just much clearer and less error-prone since you don't have to pass in the param

and this is the actual meat of the PR: being able to define a parameter at the job level easily and then use it

added the param and then moved it to the bottom so it looked a liiiitle nicer