@W-18557453 added build to update apis using a version map file

[kbode-sf]

No description provided.

[kbode-sf]

Lets discuss the approach first before finalizing the PR:

Open points concept wise:

• Is the version in the folder used somewhere should we cleans the SNAPSHOT suffix or not?
  (apis/shopper-payments-oas-1.2.0-master-b70)
• Are .metadata.json files used somewhere in the generation process?
• What tests need to be adjusted if:
• new APIs are added
• New endpoints/ schemas are added

Open points implementation wise:

• Fully replace the old update logic
• ZIP library sed causes ESL type linting errors -> is this acceptable or what other approach could be used?
• configuration file may should not be a txt file.
• test coverage

[joeluong-sfcc]

Is the version in the folder used somewhere should we cleans the SNAPSHOT suffix or not? (apis/shopper-payments-oas-1.2.0-master-b70)

yes, its used in two places:

1. To differentiate major versions of the APIs, this is needed for shopper baskets
2. Used to generate the version table in CHANGELOG.md when you run yarn run doc and/or yarn generateVersionTable

Is 1.2.0-master-b70 the version available in anypoint exchange? If so we'll probably have to update some of our scripts if we want to allow different versioning conventions

Are .metadata.json files used somewhere in the generation process?

No, this can be safely removed. It's just pulled as part of the anypoint exchange asset when we download

What tests need to be adjusted if: new APIs are added, New endpoints/ schemas are added

None at the moment except for SLAS where we have tests that test the SLAS helpers which rely on the shopper login API. There was discussion previously about also auto generating unit tests, since we have the expected return types and the expected parameters, we could generate tests and mock out the actual API call. The purpose was to catch breaking changes before they occurred, but the team decided it'd be best to implement that check at the domain team level in the SCAPI repo's CI, before specifications get pushed to anypoint exchange. Ultimately, this fell under the line in terms of priority and hasn't been touched since.

[joeluong-sfcc]

Can you add instructions in the PR description on how to test this?

I tried updating the the following API versions in api-versions.txt after checking anypoint exchange for the most recent versions:

shopper-baskets-oas=1.9.0
shopper-baskets-oas=2.1.0
shopper-consents-oas=1.1.0
shopper-context-oas=1.1.1
shopper-customers-oas=1.1.1
shopper-experience-oas=1.0.7
shopper-gift-certificates-oas=1.0.26
shopper-login-oas=1.39.41
shopper-orders-oas=1.5.0
shopper-products-oas=1.0.37
shopper-promotions-oas=1.0.36
shopper-search-oas=1.5.0 // Originally 1.3.0
shopper-seo-oas=1.0.13
shopper-stores-oas=1.0.18 // Originally 1.0.17
shopper-payments-oas=1.2.0-master-b70

and trying to run yarn run updateApisWithVersionMap and getting the following error:

    Error: 'undefined' environment not found in Salesforce organization
Error updating shopper-payments-oas (1.2.0-master-b70): Failed to download API 893f605e-10e2-423a-bdb4-f952f56eb6d8/shopper-payments-oas/1.2.0-master-b70: Command failed: anypoint-cli-v4 exchange:asset:download 893f605e-10e2-423a-bdb4-f952f56eb6d8/shopper-payments-oas/1.2.0-master-b70 /Users/joel.uong/Desktop/test_repo/commerce-sdk-isomorphic/temp/downloads --username '<REDACTED>' --password '<REDACTED>'
API u

[joeluong-sfcc]

I think this is a good solution that allows us to be precise in the versions that we release. In the past, we've had issues pulling untested versions and then having to roll back as those API OAS versions weren't ready to be released. My only concern with this approach is the overhead of tracking down these versions.

Who will be responsible for ensuring these API versions are pinned to the correct versions? The team who owns the SDK or the domain teams? I think we'll have to iron out this process to ensure no versions fall behind

[joeluong-sfcc]

The idea of this PR was to improve developer experience by not requiring developers to manually API specs correct? But they'll have to run the yarn updateApisWithVersionMap command right?

Was there any exploration into adding the yarn updateApisWithVersionMap command into the preview release CI?

[kbode-sf]

I reworked the commands a bit and update the https://github.com/SalesforceCommerceCloud/commerce-sdk-isomorphic/pull/241/files#diff-1246fcebc419eba2aaf5b810ef51db6ec5606f34da054746e1b31bdd7378405d with the instructions

[kbode-sf]

Sorry for juggling with the branches a bit.
I decided to create a new branch for the further implementation because I tested some diffs between this and the other version. This is the new PR #241. I will answer your comments here regardless and pointing to the related changes in the other banch.

[kbode-sf]

Regarding: #239 (review)

Error: 'undefined' environment not found in Salesforce organization

Error updating shopper-payments-oas (1.2.0-master-b70): Failed to download API 893f605e-10e2-423a-bdb4-f952f56eb6d8/shopper-payments-oas/1.2.0-master-b70: Command failed: anypoint-cli-v4 exchange:asset:download 893f605e-10e2-423a-bdb4-f952f56eb6d8/shopper-payments-oas/1.2.0-master-b70 /Users/joel.uong/Desktop/test_repo/commerce-sdk-isomorphic/temp/downloads --username '' --password ''
API u

I added the org-ID as constant. It worked for me because I had the cli tool configured via another option which already set the correct org-ID but now it should work without any other required env parameters.

[kbode-sf]

Is the version in the folder used somewhere should we cleans the SNAPSHOT suffix or not? (apis/shopper-payments-oas-1.2.0-master-b70)

yes, its used in two places:

1. To differentiate major versions of the APIs, this is needed for shopper baskets
2. Used to generate the version table in CHANGELOG.md when you run yarn run doc and/or yarn generateVersionTable

Is 1.2.0-master-b70 the version available in anypoint exchange? If so we'll probably have to update some of our scripts if we want to allow different versioning conventions

-> lets follow up on this in the other PR