subResults status seems to only be `changed`

[FidelusAleksander]

Are there other values here ? I've only found "changed". It would maybe make sense for kind ruleset-delete for this to be deleted and in some other scenarios a bit more informative

[joshjohanning]

Good question @FidelusAleksander! The status field was intentionally designed as a two-value outcome category:

• changed: something was modified (created, updated, or deleted)
• warning: the operation failed/was skipped

The operation detail (create vs update vs delete) is carried by the kind field; e.g., ruleset-create, ruleset-update, ruleset-delete. So if you want to know what happened, you'd check:

 - id: sync
   uses: joshjohanning/bulk-github-repo-settings-sync-action@v2
 
 - run: |
     echo '${{ steps.sync.outputs.results }}' | jq '
       .[].subResults[] | select(.kind == "ruleset-delete")
     '

Does the kind field give you what you need here, or is there a specific use case where having it on status would be materially easier? I'd want to make sure it was consistent across all settings/configuration, where applicable.

[FidelusAleksander]

Ah I understand now. I might have not ran into warnings too much and haven't noticed that.

I think it would be easier to not have to parse the actual operation detail out of the kind field and have it as a separate key with a enum value of (update/create/deleted)

That said for most settings create/delete sounds odd - but for file operations it makes sense. It caught my eye that when I was deleting and creating rulesets and there was no separate field in subresults to identify the different operations without parsing it.

I don't think I have any strong feelings or desires here yet.

[joshjohanning]

👍 I think you're totally right in that it would be way easier to have it up front for file operations and the like.

I'll keep this open as something I'll bundle along with another breaking change 💯