Hi,

I have encountered an issue after upgrading sncicd-publish-app action in the pipeline from 1.2.0 to 2.0.0. Please find the changes made to the yaml highlighted below:

Before:

• name: ServiceNow CI/CD Publish App
  id: publish_app
  uses: ServiceNow/sncicd-publish-app@1.2.0
  with:
  versionFormat: detect
  env:
  snowUsername: ${{ secrets.SN_USERNAME }}
  snowPassword: ${{ secrets.SN_PASSWORD }}
  snowSourceInstance: ${{ secrets.SN_TEST_INSTANCE }}
  appSysID: ${{ secrets.SN_APP_SYSID }}

After:

• name: ServiceNow CI/CD Publish App
  id: publish_app
  uses: ServiceNow/sncicd-publish-app@2.0.0
  with:
  versionFormat: detect
  env:
  nowUsername: ${{ secrets.SN_USERNAME }}
  nowPassword: ${{ secrets.SN_PASSWORD }}
  nowSourceInstance: ${{ secrets.SN_TEST_INSTANCE }}
  appSysID: ${{ secrets.SN_APP_SYSID }}

Pasting a screenshot of the error here. The current version is 11.4.0 and I's trying to publish 11.5.0. However the action detects 11.5.0 as current version.

Thanks
Ramya

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

All these while, we have been testing the pipeline in ServiceNow provided DPP instances. For first time today, we did a trial run of the pipeline on our organization's live instances. The pipeline threw error at the Publish step. Other Actions like servicenow-ci-cd-apply-changes and servicenow-ci-cd-run-atf-test-suite ran successfully prior to the publish step.

The application that is being published has been in the system for a few weeks now. It was deployed manually to TEST instance from sourcecontrol and Published manually from Studio in TEST until we automated it using the pipeline. Manual publish worked without any issue. Not sure if it makes any difference, we were publishing from main branch until now, but the pipeline will be publishing from the dev branch instead.

Hi @chiarnglin

When I tried to use 'detect' as versionFormat, I am getting the following error:
ENOENT: no such file or directory, open '/home/runner/work/repo-name/repo-name/sys_app_***.xml'

Below is the code snippet of how I have the Publish App step in my workflow file.

• name: ServiceNow CI/CD Publish App
  id: publish_app
  uses: ServiceNow/[email protected]
  with:
  versionFormat: detect
  env:
  snowUsername: ${{ secrets.SN_USERNAME }}
  snowPassword: ${{ secrets.SN_PASSWORD }}
  snowSourceInstance: ${{ secrets.SN_DEV_INSTANCE }}
  appSysID: ${{ secrets.SN_APP_SYSID }}

Hi @chiarnglin ,

It would be great to have the detect_without_autoincrement option that we have been using inside Azure Pipelines available on GitHub actions as well. In our model, we would want the team to set the application version manually during a sprint, rather than auto-setting it using a template.

@chiarnglin

During a manual publish from Studio, a source control tag is auto-generated. This feature is missing in the equivalent GitHub Action. We need this functionality for uniform outputs irrespective of how we do a publish, manually or from pipeline.

Thanks
Ramya

Hello, I'm using a sample pipeline with a basic publish job in my github pipeline. I have the following configuration:

1. One ServiceNow dev instance with Source Control enabled, in which I created my hello world application;
2. another ServiceNow test instance WITHOUT Source Control enabled, in which my pipeline should be able to deploy the application I created in the dev instance;
3. a public github repository that can be reached and can reach both ServiceNow instances with all the secrets and all the accounts correctly configured for each instance;
4. a dedicated user for the pipeline with admin permission on the test instance.

I'm using the ServiceNow/[email protected] to deploy my application to test instance. This is the stage:

    - name: Publish to Store
      id: sncicd-publish-app
      uses: ServiceNow/[email protected]
      with:
        versionFormat: detect
        version: "1.0.0"
        versionTemplate: "1.0"
        devNotes: "deploy-to-production-test"
        isAppCustomization: false
        incrementBy: "1"
      env:
        nowUsername: ${{ secrets.NOW_USERNAME }}
        nowPassword: ${{ secrets.NOW_PASSWORD }}
        nowSourceInstance: ${{ secrets.NOW_TEST_INSTANCE}}
        appSysID: ${{ secrets.APP_SYS_ID }}
        appScope: ${{ secrets.APP_SCOPE }}

and this is the returning error:

Warning: The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
##[debug]steps.sncicd-publish-app.outputs.rollbackVersion='1.0.0'
::set-output name=newVersion::1.0.1
Warning: The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
##[debug]steps.sncicd-publish-app.outputs.newVersion='1.0.1'
Pending
Running: 3%
Error: Unable to upload application

I've already enabled all the debugging messages but the returning error is not clear. I've already checked the secrets and they are used correctly.

We’re to not abbreviate ServiceNow with SNOW ever, according to marketing/branding guidelines. It’s either ServiceNow / SERVICENOW or Now / NOW. If you have to, it may be sn or snc in internal names but never snow. There’s another company called Snow Software doing similar things and we don’t want to get mixed up.