Publishing Store App from Pipeline

[ramyaramdasan]

With Store App configurations being a little different from that of a Custom App with baseline and custom version numbers, I am trying to understand if the existing publish-app Action would cater to Store App deployments. I assume they won't as the existing action deals with sys_app table and one version number. If it won't, will there be a new action released for Store Apps?

Thanks Ramya

[chiarng]

@ramyaramdasan we made updates to how publish app works so that you can publish application customizations for store apps, so there isn't a need for a separate action. i recommend trying out the updates to the quebec APIs, perhaps in REST API Explorer on the instance. then it'll make more sense how the updated publish app GitHub Action works, i think!

When using the GitHub Action with app customizations, make sure to set the isAppCustomization: true, and use the sys_id parameter instead of the scope.

[ramyaramdasan]

Hi @chiarnglin,

That's great news! And thanks for referring to the API docs, I often forget about them. I shall surely spend some time on it. I tried to update the pipeline for publishing Store App, but got stuck at the following stage. As you are aware, we don't auto-increment versions, in that case wonder how we should be setting the Versions. Unlike sys_app table, on sys_store_app the Customized Version field is not editable. Are we left only with auto-increment option?

Also, I have done a detailed analysis of Store App deployments using Update Sets and then switching to an App Repo based deployments. Following are the questions that I have:

1. After switching to App Repo model, the application continues to be available for Edit in Studio on ACC. In such case, what will happen during cloning of the instance with Production data which will have a version installed from the Repo?
2. Currently we use Source Control to move code from DEV to TST. We move the version update also from dev to test via Source Control. However, when we publish Custom Version from TST, DEV instance will be always on 1.0.0 version. I don't see the Custom Version showing up on the Application Manager in DEV instance.

The above tests were done on DPP instances.

Thanks Ramya

[chiarng]

@ramyaramdasan

For app customizations, you can either publish a particular app customization version number via the publish modal Or declare the version you want to publish in the API / GitHub Action. We've added a new feature to set incrementby values that you can play with, but it defaults to 0, which should be your current desired behavior? I do agree that it seems odd that the Customized Version field isn't directly edit-able on app author instances, so let me follow up on that with engineering.

I wouldn't expect the Edit in Studio functionality to still be available on an app client instance for an app customization, so that seems wrong or a bug, let me follow up on this as well...

Just to verify, you commit a new version number in DEV, then apply remote changes in TST, then publish from TST? If the TST version isn't incremented again, wouldn't DEV already be on the right version? (Trying to understand why it's stuck on 1.0.0).

Thanks, Chiarng

[ramyaramdasan]

Hi @chiarnglin,

"you commit a new version number in DEV, then apply remote changes in TST, then publish from TST? If the TST version isn't incremented again, wouldn't DEV already be on the right version? (Trying to understand why it's stuck on 1.0.0)"

Yes, you are right. The issue is that unlike sys_app record, the version field in the sys_store_app record is not editable. So, I don't have any option to set the version in DEV and move it to TEST via source control.

Will you be also able to provide me a sample workflow with incrementby and other inputs to publish a Store App?

Truly appreciate your quick responses. Thanks much!

Warm Regards, Ramya

[chiarng]

Hmm let me ask the engineering team on the first issue, see if I've just forgotten what needs to happen to edit the App Customization version directly. (You could, of course, edit it in the XML file in the Git repo if all else fails...)

I updated a template example, but you can also read the updated README docs for both publish and install app Actions. :) https://github.com/ServiceNow/sncicd_githubworkflow/blob/master/workflow_appcustomization.yml https://github.com/marketplace/actions/servicenow-ci-cd-publish-app https://github.com/marketplace/actions/servicenow-ci-cd-install-app

[chiarng]

I confirmed that this is the existing behavior today, by design. I'll take an action item to work with our engineering team on the use case. There's a few workarounds you can use for the moment:

• Update the XML file in Git repo for the sys_app_customization record with the intended version
• Commit from TEST back to Git repo with the published version, then Apply Remote Changes in Dev to pick it up.
• Update your pipeline to publish from Dev when Test passes, that way you can commit that new version number from Dev

[ramyaramdasan]

Thanks @chiarnglin for the suggestions. The reason why we chose not to use template/ auto-increment in the existing pipeline is for the flexibility of keeping minor version number same as sprint number. Unless we update the sys_app_customization in GitHub, I don't see a way we can use publish-app action in the workflow. We have not yet asked our developers to use GitHub for anything as most of them have no prior experience. Looks like we will have to use the auto-increment option for Store Apps.

Thanks for sharing sample workflows and as always for a quick response.

Warm Regards, Ramya