feat: SDK build for 22.0.

[drstrangelooker]

No description provided.

[github-actions]

APIX Tests

0 files  0 suites   0s ⏱️
0 tests 0 ✔️ 0 💤 0 ❌

Results for commit 20fca545.

[joeldodge79]

I feel pretty strongly that we should cleanup the current state of the past couple releases and release #930 as a patch before we merge 22.0 in

[github-actions]

APIX Tests

0 files  0 suites   0s ⏱️
0 tests 0 ✔️ 0 💤 0 ❌

Results for commit 3a755020.

[github-actions]

Typescript Tests

    6 files    75 suites   3m 16s ⏱️
169 tests 165 ✔️   4 💤 0 ❌
561 runs  549 ✔️ 12 💤 0 ❌

Results for commit 98e9bcf.

[github-actions]

Codegen Tests

    1 files    17 suites   30s ⏱️
397 tests 383 ✔️ 14 💤 0 ❌
398 runs  384 ✔️ 14 💤 0 ❌

Results for commit fe94373.

[github-actions]

Python Tests

    9 files      9 suites   1m 55s ⏱️
140 tests 140 ✔️ 0 💤 0 ❌
765 runs  765 ✔️ 0 💤 0 ❌

Results for commit fe94373.

[github-actions]

Typescript Tests

    6 files    75 suites   3m 14s ⏱️
169 tests 165 ✔️   4 💤 0 ❌
561 runs  549 ✔️ 12 💤 0 ❌

Results for commit fe94373.

[joeldodge79]

I reviewed the python generated code changes and it seems good to me. I briefly looked at the workflow file changes and they seem reasonable too though I haven't fully grokked all the changes.

One change we need can be accomplished in two ways.

1. separate out the "update CI for 22.0" changes (workflows etc) from the codegen for 22.0 (generated language files) into a separate PR and merge them first - that seems to be the intention with the title of this PR: chore: SDK build for 22.0
2. leave it all combined as is BUT update the title to feat: Looker 22.0 release (otherwise release-please will NOT pickup the fact that there are user facing changes in this PR because chore is not considered user facing)

[jkaster]

Agreed with Joel's feedback. Nothing further to add right now.

[drstrangelooker]

@joeldodge79 I renamed it to feat:.

[joeldodge79]

Great work on moving the CI noise-reduction effort forward!!

I'll approve this but with a note: we don't have a good mechanism for testing previous sdk versions against newer Looker versions. And maybe that's not a big deal - if something breaks then upgrade to latest SDK which DO test against all previously supported Looker versions. However, in the old workflow where we modified CI separately and beforehand to test against the next Looker release, we had at least a transient rolling window of "SDK for Looker version N works against Looker version N+1". If the generated code changes for 22.0 are merged together with the CI changes to test against 22.0 then we lose that for SDK(21.20) vs Looker(22.0). But I don't think it's critical, just pointing it out. That and my manta of keeping a PR as single purpose as possible (update CI vs generate new sdk)

[drstrangelooker]

OK. I'll do that next time.