Move Changes action locally

[edmundmiller]

Attempting to move detect changes action to a local action in this repo.

#7007 (comment)

All good - complexity is bordering on too much now. It's a shame we can't redirect individual tests to specific hardware, you know...like a certain piece of software does very well.

This manages most of the issues well. @adamrtalbot

On the complexity, after we merge this one can we migrate the action to live in this repo? I think that structure works better for the mono-repo so these PRs aren't so complicated to test/hack on. @edmundmiller

[mashehu]

What is the reason for making detect-changes local?

[edmundmiller]

What is the reason for making detect-changes local?

I added some more context; sorry! I just wanted to get the ball rolling because @maxulysse asked about it in Slack.

[mashehu]

Sorry, I still don't get it. Do you want to have the action locally just for testing purposes until we have ironed out all bugs with the sharding setup? Or permanently? What is currently not working with it when using it not locally?

[adamrtalbot]

I'm not sold on bringing detect-nf-test-changes locally. This is just cramming a whole load of additional complexity into the modules repo, which we'll have to maintain concurrently. With the current set up, we can isolate, test and maintain the code and do semantic versioning. That all goes out the window if we put it in the repo.

In my initial comment:

All good - complexity is bordering on too much now.

I did not mean let's chuck in loads of stuff creating additional complexity in the repo, I meant we should reduce the GHA set up, simplify it until it's so simple a new person can understand it instantly.

We know that people will slip in a few changes with module updates, maintain it poorly, not test it properly. I can already feel the sneaky bypass rules being added to the action to get around failed tests.