feat(ETU-75959): Add support for showing API changes in PR comment

[egrimstad]

Legg til kommentar i PR-timeline med "lesbar" liste over endringer i API-specen. Kan styre hvilke endringer man vil se med input show_changes (all/breaking/none). Gjerne sjekk om oppdateringene i README-filene faktisk er forståelige.

Eksempel fra api-spec-registry. Med show_changes='breaking'

Med show_changes='all'

[ruiyu2000]

Why dont we use https://github.com/actions/github-script instead?

[egrimstad]

Why dont we use https://github.com/actions/github-script instead?

That might be possible, I can try

[egrimstad]

Why dont we use https://github.com/actions/github-script instead?

Bleh, I think it would be kinda hacky. Since it is a reusable workflow, I don't think we can just import files from this repo like this: https://github.com/actions/github-script#run-a-separate-file So we would have to check out gha-api to get the files. Having everything be prebuilt in an action seems smoother. But I am open for a suggestion, if there is something i have missed.

I don't want the entire script to be inline, since then we don't get any type checking / autocomplete / syntax highlighting / modules.

[rikard-swahn]

Thinking this might be too much info for this README, refer to README-publish instead for these details?

I realize that the golden path include these details though ...
In that case, maybe have some short explanation of difference between "publish" and "relase" and link to README-publish?

[egrimstad]

Yes, that was my reasoning. I can't explain why one would use publish.yml with release: false unless I also explain why you would use validate.yml. Since it documents how the different workflows work together, it makes sense to have it here. But yeah.

[egrimstad]

I feel like it is pretty short already.

[rikard-swahn]

I think a practical example would be useful here, for users to understand what the use case is.

[ruiyu2000]

Bleh, I think it would be kinda hacky. Since it is a reusable workflow, I don't think we can just import files from this repo like this: https://github.com/actions/github-script#run-a-separate-file So we would have to check out gha-api to get the files. Having everything be prebuilt in an action seems smoother. But I am open for a suggestion, if there is something i have missed.

You are already using main: 'dist/index.cjs', surely gha already checks out this whole repo. Please test importing files with https://github.com/actions/github-script#run-a-separate-file
Also, I think we might as well use https://nodejs.org/learn/typescript/run-natively and skip build entirely

I don't want the entire script to be inline, since then we don't get any type checking / autocomplete / syntax highlighting / modules.

We definitely dont want the whole thing inline.

[egrimstad]

Bleh, I think it would be kinda hacky. Since it is a reusable workflow, I don't think we can just import files from this repo like this: https://github.com/actions/github-script#run-a-separate-file So we would have to check out gha-api to get the files. Having everything be prebuilt in an action seems smoother. But I am open for a suggestion, if there is something i have missed.

You are already using main: 'dist/index.cjs', surely gha already checks out this whole repo. Please test importing files with https://github.com/actions/github-script#run-a-separate-file Also, I think we might as well use https://nodejs.org/learn/typescript/run-natively and skip build entirely

I don't want the entire script to be inline, since then we don't get any type checking / autocomplete / syntax highlighting / modules.

We definitely dont want the whole thing inline.

That's different. The action is referred to using the special syntax uses: $/.github/actions/evaluate-validation which fetches it (and all related code), from the same repo and ref as the reusable workflow is defined in. I mean, I can try 🤷

Additionally, I don't want to skip build entirely, since then we have to run npm ci every time someone runs our script. Seems much more efficient to do all that stuff whenever we make changes, instead of every time.

But it does work! We need to do an extra checkout of gha-api, like this:

      - uses: actions/setup-node@v7
        with:
          node-version: 24
      - name: Checkout gha-api
        uses: actions/checkout@v7
        with:
          path: gha-api
          repository: '${{ job.workflow_repository }}'
          ref: ${{ job.workflow_sha }}
          sparse-checkout-cone-mode: false
          sparse-checkout: |
            foo
      - name: Run script
        uses: actions/github-script@v9
        with:
          script: |
            const { default: main } = await import('${{ github.workspace }}/gha-api/foo/main.ts')

            await main()
            

if the script is in a directory here called foo/main.ts. A run here: https://github.com/entur/api-spec-registry/actions/runs/36110771742/job/108888839000?pr=283

I don't really see how this is much better than referring to an action, though.

[ruiyu2000]

I suppose https://github.com/actions/github-script could remove the current runtime dependencies, but theres no guarantee that we wont need other dependencies in the future.

[egrimstad]

I suppose https://github.com/actions/github-script could remove the current runtime dependencies, but theres no guarantee that we wont need other dependencies in the future.

Yeah, except for lodash. I guess I could survive without that though.