[Denis-Averin]

Summary

Adds zizmor (static analysis for GitHub Actions) to this repository as the pilot of a fleet-wide rollout, together with the plan for the nine SDK repositories.

• doc/zizmor-rollout-plan.md: what zizmor is, measured baseline (95 findings across 30 workflows in 10 repositories with the agreed config), required workflow changes per rule, validated templates, phased rollout, the five decisions taken on 2026-11-04, SHA pins for third-party actions.
• .github/workflows/zizmor.yml: runs zizmorcore/zizmor-action (SHA-pinned) in plain mode on push, pull_request and weekly schedule. The job fails on any finding; no SARIF upload.
• .github/zizmor.yml: shared config. actions/* may stay on tags, everything else must be SHA-pinned; TEST_CONFIGURATION_ACCESS_TOKEN allowlisted for secrets-outside-env.
• check-codegen.yml, check-urls.yml: explicit permissions: contents: read, persist-credentials: false on every checkout, job names, concurrency group. This resolves all 6 zizmor findings this repository had.
• codegen/github/ templates and scripts/sync-github-templates.bash (Phase 1): the canonical zizmor workflow and config, copied into every SDK by codegen/generate-*.bash and checked by the new "Check shared GitHub config in sync" job.
• Phase 3: doc/ci-security.md (the CI security requirement and how this repository meets it, new row in cloud-sdk-requirements.md), a make zizmor pre-flight step in ReleaseWorkflow.md, and scripts/enforce-zizmor-check.bash, which an organization owner runs with gh to require the "Run zizmor" check on every default branch (ruleset per repository, admin bypass for the direct release pushes) and to set the organization's default GITHUB_TOKEN to read-only.
• No Dependabot: decision 5 was revised the same day to roll out zizmor without .github/dependabot.yml for now; the action pins are bumped by hand.

Verification

• All four .github files audited locally with zizmor 1.30.1: zero findings under regular, pedantic and auditor personas, --strict-collection on.
• persist-credentials: false on the check-submodules job is the one behavioural change to watch: all submodules are public, so git submodule update --remote should not need the job token. The existing "Check submodules" job on this PR is the test.
• scripts/enforce-zizmor-check.bash: bash -n, the ruleset JSON parsed, --dry-run prints the intended calls. It could not be run against the API from the sandbox (no gh login), so the first real run is the test; it is idempotent.

Next

Phase 2 (one chore/zizmor PR per SDK) is open in every SDK repository; see the plan's status notes. After those merge, run scripts/enforce-zizmor-check.bash once.

[Denis-Averin]

CI status note: "Check swagger specification up-to-date" is red, and it is not this PR's.

What fails: the check-swagger job curls https://api.aspose.cloud/v4.0/barcode/swagger/spec and diffs it against spec/aspose-barcode-cloud.json. The diff in the job log shows content the live API now serves that the committed spec does not have: BatchGenerateRequest, BatchGenerateItem, BatchArchiveFormat, a new JapanPost enum value.

Why it is not this PR's: this PR does not touch spec/ or that job's command (only persist-credentials: false on the checkout step, which ran fine). The same strings are absent from spec/aspose-barcode-cloud.json on main as well (fcbac0f, Release 26.10), so main would fail the same way on a re-run. The last green run on main was 2026-10-19; the live API changed after that.

Fix: none inside this PR. The spec is refreshed by make update (scripts/update_swagger_spec.bash), which is the first step of the release flow and regenerates the SDKs, so it belongs in the next release branch rather than here. Until then this check stays red on every PR against main.

Everything else on this head is green: Run zizmor, Check all submodules up-to-date (with persist-credentials: false), Check all URLs, Dependabot config validation.

[Denis-Averin]

CI status note: "Check all submodules up-to-date" turned red on the last two pushes, and it is not this PR's.

What fails: the job runs git submodule update --recursive --remote and then git diff --exit-code. Since 11:06 UTC the main branches of two SDKs have moved past the commits this repository points to: .NET (c7b05a3 → 510b4b9, PR Aspose.BarCode-Cloud-SDK-for-.NET#135) and Node.js (04f2af1 → f3e55f2, PR Aspose.BarCode-Cloud-SDK-for-Node.js#159), both the ln -F fixes for the Ubuntu 26.04 runners. The diff is those two pointer changes, so main fails the same way; the previous run on this PR (10:5x UTC, before the merges) was green with the same workflow file.

Why it is not this PR's: the PR does not touch submodules/ or .gitmodules, and the job's own change here (persist-credentials: false) worked on every earlier run.

Fix: a submodule bump, as in the "Update … submodule" commits on main:

git submodule update --remote submodules/dotnet submodules/node
git commit -am "Update dotnet and node submodules"

Not pushed here, since it is unrelated to zizmor; it belongs in its own PR against main, ideally once the Java, PHP and Python ln -F PRs are merged too, so one bump covers all five. "Check swagger specification up-to-date" is skipped while this job is red and remains the separate release item noted above.

[Denis-Averin]

The submodule bump is PR #160 (dotnet, java, node, php and python, all five ln -F fixes are merged now). "Check all submodules up-to-date" stays red here until #160 is merged and main is brought into this branch.