Regenerate services 2022-06-24

[endgame]

It's about time we did one of these, as part of the plan to catch up to recent AWS service definitions. This pulls in various recent generator/service-definition changes:

• More things are now sorted in the service definitions so we shouldn't have as much churn in the generated output.
• amazonka-pinpoint should work properly; @newmana please check.
  • amazonka-glacier changed in similar ways, which I think means it now works but I don't know if we have any users.
• amazonka-sso copies amazonka-sts's style of typeOverrides in the service configs to splice in amazonka-core types for Access Key ID, Secret Access Key, and Session Token fields. @pbrisbin please check that I haven't broken SSO for you.
• amazonka-sts declares the Credentials field required in all AssumeRole* responses.

The only interesting commits are:

• https://github.com/brendanhay/amazonka/commit/e4bed95ab1ac9e8be2b2b7881550006403228859 : let the generator script proceed to committing
• https://github.com/brendanhay/amazonka/commit/1566947a7eae0eacb1afbfbe047557eee13eca96 : support the changed STS/SSO bindings.

Once this is done, the next steps will be to advance to the latest botocore pin, generate again, and then start configuring missing service definitions.

Fixes #765

[endgame]

There's a missing API key in the workflow runs, possibly because the PR branch is coming from a fork. I don't have enough permissions to play around with the config here, so I think it's a @brendanhay thing to fix that.

[pbrisbin]

@pbrisbin please check that I haven't broken SSO for you.

:heavy_check_mark: I updated an app to this commit and confirmed it still works.

[endgame]

Thanks @pbrisbin. It would also be good if @K0Te could report that sts:AssumeRoleWithWebIdentity works. But we have stuff deployed at work that's running off this branch using other STS functions so I'm happy to merge later this week.

[K0Te]

Hi @endgame ,

I've just migrated my project to this PR branch, will test it tomorrow and report any issues. Project uses the following services: amazonka-lambda, amazonka-sts, amazonka-s3, amazonka-cloudfront, amazonka-route53, amazonka-sqs, amazonka-ssm.

I've used a patched 1.6.1 version before, so there were a lot of code changes. Migration was smooth, except for a few cases where a generic lens for a field is different from a regular lens. For example: Amazonka.Lambda.Lens.functionCode_zipFile, Amazonka.SSM.Lens.parameter_value. This is probably a design feature, not a bug, right?

[endgame]

Thanks for the good news @K0Te. I hadn't noticed that difference before - looks like the generator is smart enough to unwrap through things like Sensitive and Base64, and if you use a generic lens you'll have to use the _Sensitive and _Base64 isos yourself (they should be exported by Amazonka, hopefully.

[endgame]

@brendanhay that might be a good reason not to deprecate generated lenses?

[brendanhay]

Ideally we want to continue to improve the codegen enough that it inserts the equivalent of Sensitive and Base64 newtypes at de/serialisation points - ie. o .: "field" <&> fromSensitive, so the user never has to deal with un/wrapping said newtypes. (But do this as plain functions instead of how it currently changes the types of the record fields - ie. drop the newtypes completely.)

[K0Te]

@endgame I've tested what I could - everything seems to work correctly, including sts:AssumeRoleWithWebIdentity.