ServiceNow / sncicd_githubworkflow

.yml sample pipeline template for workflow
MIT License
21 stars 39 forks source link

The workflow pipeline fails with getaddrinfo ENOTFOUND ***.service-now.com for instances configured with a different domain name. #9

Open nadimrizk83 opened 2 years ago

nadimrizk83 commented 2 years ago

The workflow pipeline fails with getaddrinfo ENOTFOUND ***.service-now.com for instances configured with a different domain name.

When looking further into our instance configuration, we do have the following set: instance_name: abcd123 instance_ID: xxxxxxxxxxxxxxxxxxxxxxxxx instance_domain_suffix: servicenowservices.com

We do also have custom URL enabled and configured for the instance; however we can still resolve and access the instance using: abcd123.servicenowservice.com

The problem is that we can't change the domain_suffix as this is already configured and registered.

Looking further at your code; I do see that service-now.com is hard coded and appended in many places in each of the actions source code where the instance URL is being generated.

These actions should be portable and applicable to customized instances and not just to out of the box servicenow instances; therefore I would suggest enhancing the code to parameterize the domain name defaulting to service-now.com but with the option to pass it as one of the secrets in the case where customized instances have the need to do so.

We would like to leverage these actions but unfortunately we're failing on the first step due to the domain name limitation.

Also the pipeline does not fully work in personal development instances (PDI) - mainly the publish part fails as publishing capabilities have been disabled for PDI; therefore the publishing action works only with licensed instances where publishing has been enabled - It is also worth including this note for community there is awareness. It failed on me multiple times in my PDI environments and that's why I had to switch to our org instances where now I am facing domain related issues as described above.

Would appreciate some insight on how we can get over this issue so we can start leveraging these actions.

chiarng commented 2 years ago

Thanks for the detailed report. I agree that many customers use proxies, and it would be helpful to configure that as a part of the parameters in GitHub Actions, but unfortunately we currently don't have the engineering bandwidth to develop this feature. As a workaround, would it be possible for your team to identify the SN cloud hosted URL to grab the subdomain to use for your pipeline? (i.e. work outside of your proxy).

The PDI issue is because those PDIs are not connected to a Store instance for access to an application repository, and therefore cannot publish/install applications. We are aware of the issue, but it similarly faces prioritization and engineering bandwidth challenges to address. If you don't mind, you can try a workaround by setting up another PDI as an application repository instance to connect to:

https://store.servicenow.com/sn_appstore_store.do#!/store/application/a8a6a9135f02301011d57104c173138d

https://docs.servicenow.com/bundle/rome-application-development/page/build/applications/concept/manage-store-app-air-gapped.html

// as global on the client instance gs.setProperty("glide.test_instance","false"); gs.setProperty("sn_appclient.repository_base_url", "https://{name of your app repo instance}.service-now.com/"); gs.setProperty("sn_appclient.upload_base_url", ""); gs.setProperty("sn_appclient.repo_auth_name", "sn_repo.AppRepo"); gs.setProperty("sn_appclient.client_calls_allowed", "true"); gs.setProperty("sn_appauthor.upload_base_url", ""); gs.setProperty("sn_apprepo.credential", "{any string of your choosing}");

// as sn_appauthor on the client instance new ConfigChecker().checkForChanges();

nadimrizk83 commented 2 years ago

Hello! Thank you for your reply.

In regards to the first item:

The Custom URL we use is: service-sandbox.xxx.xxx.xxx

The instance parameters listed in sys_properties table are as follow: instance_name: abcsandbox instance_domain_suffix: servicenowservices.com instance_id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

so I can access the instance either through: service-sandbox.xxx.xxx.xxx or abcsandbox.servicenowservices.com

We can't change the instance_domain_suffix parameter unfortunately - I can't access the instance when I use abcsandbox.service-now.com

The value that I am passing in the pipeline is: abcsandbox which I believe is subdomain you're referring to.

Please correct me if I am wrong on this one here and what other alternatives we have to make this work.

As for the second topic (PDI); I will give it a shot based on what you proposed hopefully I would be able to test it.

chiarng commented 2 years ago

If your instance is hosted on ServiceNow's cloud, there definitely is a public endpoint for it, even if it's routed through multiple proxies on your end.

Your alternatives would be to

  1. Fork these repos and publish your own private github actions with your domain hardcoded
  2. Fork these repos, write code to have additional optional parameter to input alternative domain, contribute feature as a PR.