Implement fork check for release task

[MattyTheHacker]

No description provided.

[MattyTheHacker]

i believe this should now work

[CarrotManMatt]

Why does github.repository not work for the pull request event too. That way it can be simplified?

[MattyTheHacker]

Why does github.repository not work for the pull request event too. That way it can be simplified?

Annoyingly, github.repository returns the target repository for pull requests, not the originating repo. See the logs from #408 -

I can't seem to find any documentation that explicitly states this, but it appears to be the case

[MattyTheHacker]

however don't actually merge this yet - noticed something wrong

[MattyTheHacker]

right that should be good now

[Copilot]

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[MattyTheHacker]

wait I've just had a thought - surely there's no way a push not on this repo can trigger a workflow, right? so the push check actually isn't needed at all?

[CarrotManMatt]

If a pull request is the only event that can trigger this workflow from another repo then surely we want to allow all other events in this check, not just push. This is so that we don't need to add the new event types to the triggers as well as this check in the future.

Would something like this work?

github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name == 'CSSUoB/TeX-Bot-Py-V2'

[MattyTheHacker]

If a pull request is the only event that can trigger this workflow from another repo

I don't know this 100% i was more hoping you would know lol, but yeah if that's defo the case the check can be simplified

[MattyTheHacker]

If a pull request is the only event that can trigger this workflow from another repo

I don't know this 100% i was more hoping you would know lol, but yeah if that's defo the case the check can be simplified

just checked, and even if a push from an external fork could trigger a workflow, our workflow specifically only runs on pushes if it has a version tag, which a fork would (read: should) never have so have simplified the check

[Copilot]

Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (1)

.github/workflows/check-build-deploy.yaml:222

• Accessing 'github.event.pull_request.head.repo.full_name' without verifying that 'pull_request' exists may lead to an evaluation error when the event is not a pull_request. Consider adding a check to ensure 'github.event.pull_request' is defined before accessing nested properties.

github.event.pull_request.head.repo.full_name == 'CSSUoB/TeX-Bot-Py-V2'

[CarrotManMatt]

our workflow specifically only runs on pushes if it has a version tag, which a fork would (read: should) never have

Not sure I fully understand this?

1. Our workflow runs on push of a version tag or pushes to main
2. If somehow a fork push could trigger this workflow, that fork could still push to their main branch or push a version tag to their fork