Expected handling of publishing for "Whats New" metadata

[justinseanmartin]

I'm trying to one-shot the publish with the asc publish appstore command, but I end up getting an error back that I'm missing the "Whats New" metadata.

Waiting for build 78 (1.5.0) to appear in App Store Connect...
Submit preflight failed: submission-blocking localization fields are missing:
  - en-US: whatsNew
Fix these with `asc metadata push` or `asc apps info edit` before retrying `asc publish appstore --submit`.
Error: publish appstore: submit preflight failed

What is the expected workflow to avoid this? Use asc release stage? I thought the point of consolidation into the asc publish appstore command was to streamline those steps. If there were a asc submit command for starting a new review submissions, I'd add some error handling, but it seems from the docs like this has been intentionally omitted and steering folks towards asc publish instead.

I also see in the error message to call asc publish appstore --submit a second time. That errors out with:

> asc publish appstore --app <APPID> --ipa .asc/artifacts/<APP>-1.5.0-78.ipa --submit --confirm
Error: publish appstore: failed to create upload record: The provided entity includes an attribute with a value that has already been used: The bundle version must be higher than the previously uploaded version.

FYI - I'm explicitly supplying an explicit --build-number param, because I check that value into source code for tracking purposes. I think that makes my workflow non-standard and in the standard flow (and not using the --ipa param here), it would just bump the version number, rebuild, and submit another build (which is a bit wasteful, but probably not a huge deal).

Would you be willing to take a --metadata-dir param on the publish command and have that be set that right after publishPlanStepEnsureVersion? Or alternatively allow asc release stage to operate without a --build param, which would just run the ensure_version and apply_metadata actions?

Thanks!

[rudrankriyam]

Good question; will let you know tomorrow

[justinseanmartin]

Bumping to make sure it didn't fall off the radar. I'm happy to implement whichever solution is deemed best, but I'd like input before starting to avoid throwaway work. If both seem like reasonable additions, I'm also happy to implement them both. They both seem like they'd fit the needs, though adding --metadata-dir seems preferable if the goal is to make asc publish appstore the single unified command rather than needing to chain multiple calls together.

A third approach would be to have some way to recover gracefully from the publish failure due to missing metadata. This would require a failed submission followed by a successful one, which seems roundabout and confusing, so probably not something you'd as the expected behavior of a script, but potentially could be helpful for error handling. If you did, one way could be to add some option to asc publish appstore to skip the build and reuse the existing uploaded artifact. That seems like it potentially breaks the intent of publish action however and could end up publishing the wrong artifact by accident. It'd probably be cleaner to restore asc submit create to recover (after a asc metadata call), but I understand that it was removed intentionally to steer people towards using asc publish as the canonical way to get things into the AppStore. Having a clean way to handle recovering from a publish failure is slightly less important (at least for my scenario of missing metadata) if there is a way for me to avoid the failure in the first place.

[rudrankriyam]

@justinseanmartin

--metadata-dir on asc publish appstore is the direction I prefer

The current publish appstore flow uploads, ensures the version, attaches the build, and then runs submit preflight. It does not currently have the metadata application step that release stage has, so missing whatsNew can fail after the upload has already succeeded. With a fixed --build-number, retrying the same publish command then tries to create another upload record and ASC rejects the duplicate bundle version.

I can review the PR adding --metadata-dir to asc publish appstore, applied after ensure/create version and before attach/preflight. That keeps publish appstore as the single one-shot command.

I would not restore asc submit create; the current path is asc review submit after applying metadata and resolving the uploaded build ID.

I also wouldn’t make release stage work without --build as the main fix, because that weakens the contract, as it is supposed to mean “prepare this exact build for review,”

[justinseanmartin]

This was addressed in #1485 and released in version 1.4.0.