Code Generation Tracking

[migueldeicaza]

It would be useful to have a GitHub action that can show and compare changes before-and-after changes to the code generator are done, for a quick inspection of the changes.

Like the #557 change, this would require us to store somewhere the "previous" version of the code I think (I do not want to check-in generated code into GitHub).

Or maybe have the code run twice, but unclear how I would get a "previous version of the generator"

[elijah-semyonov]

swift package diagnose-api-breaking-changes main --targets SwiftGodot

Performs checkout and full build with plugin of both current and specified revision. Doesn't seem to be correct on my machine and doesn't detect breaking changes though

[samdeane]

I think an action that is triggered by a PR has access to the commit that the PR is merging into, as well as the commit that triggered the action?

So there should be nothing to stop an action checking out and running the generator tool against both commits, then diffing the results.

[samdeane]

https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#running-your-pull_request-workflow-based-on-the-head-or-base-branch-of-a-pull-request

[samdeane]

I've been looking for a way to get GH to show a nice diff across the output of an arbitrary diff command, but so far I've not found anything.

The easiest way to do this might actually be to check in the generated files, but mark them with .gitattributes so that by default GH ignores them in diffs: https://thoughtbot.com/blog/github-diff-supression

I don't like committing generated files in principle, but my main objection is that they clutter up the diff -- so if the attributes solve that, it might be ok.

Apparently you can still click into the diff if you want to see it.

[samdeane]

Alternative strategy

• create a repo containing the generated code
• have a workflow which does the following for any PR:
  • run the generator using the PR's code
  • commits it to the generated-code repo
  • tags the commit it with a tag that is derived from the commit SHA from the main repo (eg generated-234a3bc)
  • works out the corresponding tag in the generated-repo for the head commit of the branch that the PR is merging into
  • craft a Github link showing the diff between the two tags in the generated-repo
  • output that in the workflow report