Hi all ! I set up a CI/CD flow based on this SALTO documentation : https://www.salto.io/blog-posts/netsuite-ci-cd-pt2 . It worked very well until the beginning of this year and the removal of OAuth 1.0 Token-Based Authentication Support in SuiteCloud SDK. The evolution of the SuiteCloud SDK connector version 25.1 requires me to switch to the CLI command accountsetupci and use an authentication certificate. The generated certificate works fine when used in the terminal, but I get an error when running in my workflow action on github repository

Unexpected error. Verify the certificate file /home/runner/work/repo-name/repo-name/privatepem.

I’m not sure of the best way to store the private certificate and call its path ?

i believe the idea with the

SUITECLOUD_CI_PASSKEY

environment variable is to make authids securely portable, so if you have defined your authids in the cli then you can store the generated

credentials_ci.p12

file and set the passkey environment variable to decrypt it when it runs (the passkey must be the same value used to create the authids to decrypt them). i haven't tried this myself but i believe that is the way rather than storing the certificate itself and making the authid on the fly

I don't see any reference to a SUITECLOUD_CI_PASSKEY, but my suggestion for 2025 is to leverage NetSuite OAuth2 M2M auth for the SDF actions that touch NetSuite (in the context of CI/CD)

that's it yeah, using

suitecloud account:setup:ci

(M2M auth method, using a certificate) puts your authids in a file

credentials_ci.p12

(located in

~/.suitecloud-sdk/

on mac, not sure where it goes on windows) that you can (if i'm not mistaken) then use in ci/cd since it's encrypted and requires the

SUITECLOUD_CI_PASSKEY

environment variable to be set to the same value to decrypt it. unless i'm missing some other way to use M2M authentication in a github action? that would be handy to know

I don't really understand the point of complicating things with SUITECLOUD_CI_PASSKEY. I just stick the certificate into an environment secret in github

- name: Deploy
        uses: actions/github-script@v7
        env:
          NS_ACCOUNT_ID: ${{ vars.NS_ACCOUNT_ID }}
          NS_CERTIFICATE_ID: ${{ vars.NS_CERTIFICATE_ID }}
          NS_PRIVATE_KEY: ${{ secrets.NS_PRIVATE_KEY }}
        with:
          script: |
            const script = require('./scripts/deploy.js');
            await script({github, context, core, exec, dryRun: false });

/**
   * Save the token for SDF. To improve performance, instead of running this for each project we are
   * validating, we will use the legacy project here and manually generate a project.json for each
   * project.
   */
  async function saveSDFToken() {
    const { NS_ACCOUNT_ID, NS_CERTIFICATE_ID, NS_PRIVATE_KEY } = process.env;

    const cwd = `./src/${LEGACY_PROJECT_NAME}`;

    await fs.promises.writeFile(`${cwd}/private.pem`, NS_PRIVATE_KEY);

    await exec.exec(
      `npx suitecloud account:setup:ci --account ${NS_ACCOUNT_ID} --authid ${NS_ACCOUNT_ID} --certificateid ${NS_CERTIFICATE_ID} --privatekeypath private.pem`,
      [],
      { cwd }
    );
  }

it is a bit weird that suitecloud can't use the private key directly from the environment variable given how common that pattern is for secrets

Hi - sorry to barge in on this thread, but I'm having trouble using the

credentials_ci.p12

file I've generated in order to validate my ACP project. I keep getting this error:

Secure storage is inaccessible. Ensure that the secure storage in your system is properly configured and accessible.
For more information, see <https://system.netsuite.com/app/help/helpcenter.nl?fid=article_1210060428.html>.
Error: Process completed with exit code 1.

as far as i can tell the suitecloud cli doesn't accept the private key as an environment variable because it doesn't expect the use case of creating new authids on the fly, instead expecting you to create your authids once (or once every two years/when the certificate expires), store them encrypted wherever needed, and decrypt them on the fly using the passkey (which is stored as an environment variable as it is meant to be used in a ci environment like this). personally that does seem less complicated to me, i only need to create my authids once and i know they will be the same wherever i use them, and i don't need to store the private key or certificate id anywhere, just the passkey. but if you often need to interact with new accounts then you'd need to update the credentials file with the new authids each time which could get annoying whereas creating them on the fly the private key and certificate id are always the same so 🤷