Publish the regenerated standard via a pull request

[MichaelLeeHobbs]

Fixes #116

The problem

The update-standard workflow is not failing any more — it succeeded in April, May, June and July 2026, with every step green including tox.

What is missing is the step that lands the result. It is commented out:

# temporary disable "publish to master", which may commit the changes in an unapproved PR
# - name: Publish to master

So each month the workflow downloads the current standard, regenerates standard/*.json, verifies it against the test suite, uploads it as a build artifact — and discards it. The published JSON has not changed since rev2024b (2024-04-18).

The change

Replace the disabled step with peter-evans/create-pull-request, so regenerated data is proposed rather than pushed. This keeps the property that caused the original step to be disabled — nothing reaches master unreviewed — while letting updates land again. The step is gated on tox passing and on there being a real diff.

Also removed continue-on-error: true from the test job, which caused the workflow to report success even when a step failed.

Scope is deliberately one file and one concern. The workflow also raises Node-20 deprecation warnings on actions/checkout@v4, setup-python@v5 and the artifact actions; those bumps are worth a separate PR.

Tested end to end

Run on a fork with this change: https://github.com/MichaelLeeHobbs/dicom-standard/actions/runs/30175516319 — all steps green, including Open pull request, which produced MichaelLeeHobbs#1.

That PR contains exactly the 11 standard/*.json files and nothing else (add-paths scopes the commit), and tox passed against the regenerated data before it was created.

The diff is two years of accumulated updates: +651,911 / −479,771 lines across 11 files.

File	Change
module_to_attributes.json	+553,760 / −422,864
macro_to_attributes.json	+94,529 / −56,116
attributes.json	+1,624 / −4
ciod_to_modules.json	+715 / −71
references.json	+535 / −507
confidentiality_profile_attributes.json	+280 / −2
modules.json	+133 / −61
ciods.json	+115 / −91
ciod_to_func_group_macros.json	+100 / −23
macros.json	+80 / −32
sops.json	+40 / −0

Required one-time repository setting

create-pull-request uses GITHUB_TOKEN, which cannot open pull requests unless this is enabled:

Settings → Actions → General → Workflow permissions → "Allow GitHub Actions to create and approve pull requests"

Confirmed necessary and sufficient during testing. Note the fork used for the test has the restrictive Read repository contents default, and the PR was still created — the job-level permissions: block in this workflow grants what is needed, so that default does not have to change.

Without the setting the workflow will run and fail at the final step with "GitHub Actions is not permitted to create or approve pull requests." If you would rather not enable it, the alternative is to have the workflow push the branch and leave opening the PR to a human — happy to rework it that way.

What this closes

This closes #116 only. Merging a workflow change regenerates no data, so the stale-data issues stay open until the first automated data PR is merged.

I checked those against the regenerated output from the test run, and all three are resolved by it:

• Segmentation CIOD not up-to-date with latest standard #126 — segmentation-image:00620001 now reads Enumerated Values: BINARY, FRACTIONAL, LABELMAP. It currently ships with only BINARY and FRACTIONAL.
• Wrong attribute position - Subjective Refraction Measurements Macro > Vertex Distance (0022,000F) #125 — Vertex Distance is now at subjective-refraction-measurements:0022000f, i.e. at macro root. It currently ships nested inside Prism Sequence (0046,0028) — the 2024b defect NEMA corrected in 2024c.
• Table E.1-1 Confidentiality Profiles Incomplete #74 — confidentiality_profile_attributes.json goes from 621 to 656 rows, matching the 655 tag-bearing rows in the current Table E.1-1.

I have deliberately not written Fixes for those three, since it would close them before the data they describe has actually changed. They should be closable immediately after the first data PR merges.

One unrelated bug noticed while checking

The 656th row of confidentiality_profile_attributes.json is spurious, in both the current and regenerated output:

{"name": "Private Attributes", "tag": "(GGGG,EEEE) WHERE GGGG IS ODD", "id": "ggggeeee-where-gggg-is-odd"}

It comes from slugifying the "(gggg,eeee) where gggg is odd" private-attribute line of Table E.1-1 as if it were a tag. Unrelated to this change and not fixed here — happy to send a separate PR if useful.