Branch diff is always null about pscale-workflow-helper-scripts

[jonico]

Would it be possible to share a workflow run?

Do you see any different behavior if you refreshed your schema in the deploy request after the update and then ran /ps-update again without any parameters?

[jcohenho]

@jonico I'm not sure how to share a workflow run, how do you suggest I do this?

I refreshed the schema in the DR and then ran /ps-update again with no parameters. Still the same outcome.

I also had a colleague try to approve the PR via /ps-approve, and the workflow run gave us the following error:
Error: Deploy request authors cannot approve their own deploy requests.

I have a separate question -
I noticed the scripts automatically committed a .pscale/env/ps-env-add-status-to-scans.sh file (based off the branch name) with environment variable configuration to the PR. Is this expected behavior? If so, won't these files grow after a while? Are we supposed to delete them as time goes by? What is your strategy here? Thanks!

[jonico]

@jcohenho: I was hoping your workflow ran in any public repository where you could have shared the link with me.

Based on your observations about the "not being able to approve your own DR" it seems as if you have set PlanetScale service tokens (as opposed to the web based auth flow where the individual user's credentials are used).

Approvals would only work if every user was to use their own credentials (e.g. by clicking on the auth links in the workflow run when no service tokens are used).

If you are actually using service tokens (please confirm), I wonder whether the scope of those tokens contain the necessary permissions to diff the schema with the production branch - can you grant the service token more scopes temporarily and check?

Regarding the commits created in the subdirectory- this was my way of keeping track on the association between PR and deploy request in a traceable manner that would still show if the code was imported somewhere else.

That said, this entire IssueOps based integration is just a proof of concept where we are looking forward to more feedback how to make it better and also looking forward for any contributions.

In the mid-term, our goal is to turn the GitHub workflow based approach into a proper GitHub app but until then, we like to get feedback on the usefulness of the workflow itself and what additional features are needed/which features don't make sense in their current form.

[jcohenho]

@jonico Sorry, my workflow run is in a private repo - I've been using service tokens as you guessed, I'll try the web-based authflow instead and see if that works. Once I can connect everything and properly test out these workflows I can provide better feedback. Thanks for all your hard work!

[jcohenho]

@jonico I tried to use the web-based authflow and I'm getting the same results. The deploy branch attaches successfully, but the schema changes are still null. Any other ideas?

[jonico]

I will try to reproduce this week and let you know

[jonico]

@jcohenho: I experimented with #21 can could not reproduce your issue, can you check the workflow logs linked in the PR and tell at which point they differ from your workflow logs?

[jonico]

closing issue, feel free to reopen if needed