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

Kevin Ryan Khan — Wed, 04 Nov 2026 14:39:14 +0000

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 feeling: you open a pull request and you cannot tell, from the diff, what actually changed in the project. A rename here, a script swapped there, a dependency added quietly in a file you were not watching — and the only way to be sure is to go and look.

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. The Action answers them before the review starts.

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.

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 report wrong numbers, miss findings, or claim a check had passed when it had not. Thirteen issues came out of that pass — an off-by-one in a page count, a file counted twice, a false pass on a repository that was not, in fact, an SDF project.

We held the release until all thirteen were fixed, each with a permanent regression test — a test that stays in the suite and fails the build if the bug ever returns. That includes the uncomfortable cases: 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 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 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.