Open nadimrizk83 opened 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:
// 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();
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.
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
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.