November 4, 2026 netsuitegithub-actionsopen-source

See what every pull request changes — and catch what it introduces

SDF Analyzer — PR Check is a free GitHub Action from Strikaris for teams who build on NetSuite’s SuiteCloud Development Framework (SDF) — Oracle’s system for holding a NetSuite account’s customizations as files in a code repository. On every pull request, it posts one comment — updated in place on each new commit, never spammed — containing your script inventory, your dependency map, sanity checks on the project, and pattern checks on the files the pull request changed. It runs entirely on the GitHub runner inside your own repository: your code never leaves your GitHub account, and no Strikaris server is involved. It is MIT-licensed — free to use, and the code is public.

The whole install — one workflow file:

name: SDF Analyzer — PR Check
on: pull_request
permissions:
  pull-requests: write
jobs:
  pr-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: Strikaris-Tech/sdf-analyzer-pr-check@v1
        with:
          project-path: '.'

Everything below is the detail.

Your SuiteCloud project is a black box at review time. Every NetSuite team that works in SDF knows the same moment. A pull request arrives with twenty changed files. Some are SuiteScripts, the JavaScript files that run inside NetSuite as record automations, integrations, and scheduled jobs. The reviewer is expected to approve them. But nothing in the pull request answers the basic questions:

How many scripts does this project actually contain?
Which built-in NetSuite modules (the N/ modules, such as N/record and N/search) do those scripts depend on?
Did this change add a script, remove one, or quietly break the project file that ties everything together?

Reviewers answer those questions by opening files one at a time, or they stop answering them at all and approve on trust.

What the comment contains

A script inventory. Every SuiteScript in the project, with its type (read from the @NScriptType annotation every SuiteScript carries: User Event, Restlet, Map/Reduce, and the rest), its API version, and how many modules it depends on.
A dependency map. The unique N/ modules used across the whole project, and how many scripts use each one — the fastest way to see what a change really touches.
Sanity checks. Plain warnings for the failures that otherwise surface late: a missing or unparseable manifest.xml (the project definition file), a missing SuiteScripts directory, and scripts that fail to parse at all.
Pattern checks. The files the pull request changed are checked for six patterns: a hardcoded credential written into the source, dynamic code execution (eval and its equivalents), an empty catch block that swallows errors silently, a log call carrying a credential- or personal-data-shaped value, a call to a retired SuiteScript 1.0 API (nlapi… / nlobj…), and a synchronous web call in a client script. Each changed file is compared against its version on the base branch, and only findings the pull request introduces are reported — pre-existing findings in the same files are not.

SDF Analyzer — PR Check running on a pull request

Used as a merge gate, it can also fail the run. Two options, independent of each other and both off by default: set fail-on-issues and the run fails when any sanity warning is found; set fail-on-findings and the run fails when the pattern checks report new findings.

Project mode. If your repository holds an SDF project, you get the full behaviour above, in either of the layouts SDF accepts.

Loose-file mode. If it does not — if you simply have SuiteScript files in a repository, as many teams do — the Action inventories those loose files instead, with their types and dependencies, says plainly that no project was found, and runs the same pattern checks on pull requests. And if a repository contains neither a project nor any SuiteScript, the comment says exactly that. It never reports a bare zero as if a check had passed.

We tried to break it before we shipped it

Before the first release, we ran an adversarial pass against the Action: a deliberate attempt to make it fail, mislead, or stay silent — oversized projects thousands of files deep, paths nested a hundred folders down, corrupted file encodings, manifests with the wrong shape, repositories arranged to produce a comment too large for GitHub to accept. That last one was real: on a large enough project, the comment could exceed GitHub’s size limit, the post would be rejected, and the run would fail with nothing shown at all. The pass found thirteen defects in total.

We held the release until all thirteen were fixed, each with a permanent regression test — a test that keeps that exact failure from ever coming back. That includes the uncomfortable cases a tool like this must get right: a mistyped project path now fails loudly instead of reporting an empty repository, and a file that merely mentions the SuiteScript annotations in a string or a comment is no longer counted as a script. Version 1.0.0 shipped only when the count reached zero. The suite has grown with the tool since: the Action now carries 149 automated tests.

Install

name: SDF Analyzer — PR Check
on: pull_request
permissions:
  pull-requests: write
jobs:
  pr-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: Strikaris-Tech/sdf-analyzer-pr-check@v1
        with:
          project-path: '.'

Save that as a workflow file in your repository (for example, .github/workflows/pr-check.yml). There is no sign-up and no account — and if it is not for you, removing it is deleting the file. The Action is on the GitHub Marketplace: https://github.com/marketplace/actions/sdf-analyzer-pr-check — and the code is public, if you would rather read it first: https://github.com/Strikaris-Tech/sdf-analyzer-pr-check

What it deliberately does not do

The free tier is inventory, dependency map, sanity checks, and the six pattern checks — nothing more. The pattern checks examine only the files a pull request changed, for the six patterns above. They are not an audit: the rest of the project, data flow within and between files, deployments, roles, and configuration are not examined. The Action does not link scripts to their deployment records, does not evaluate governance or compliance rules, and does not produce diagrams or audit reports. For a deeper, human-reviewed audit of a NetSuite project — deployment linkage, findings with line-level evidence, and a remediation report — Strikaris offers the SDF Analyzer Audit service.

Try it

One pull request is enough to know whether it earns its place:

name: SDF Analyzer — PR Check
on: pull_request
permissions:
  pull-requests: write
jobs:
  pr-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: Strikaris-Tech/sdf-analyzer-pr-check@v1
        with:
          project-path: '.'

https://github.com/marketplace/actions/sdf-analyzer-pr-check

Dedicated to Brandon Lee Zeek, co-founder of Strikaris — the other half of the work that led here.