> I have so many "trash" commits trying to fix or debug a pipeline and so much of it's just throwing stuff at the wall to see if it sticks.
One tool is to use draft PRs for this - you can run changes to your action YAML from the draft PR. When you are happy just squash the commits as you see fit on a "real" PR to merge the changes in without the mess.
I've found draft PRs for debugging/developing GH action logic to be pretty reasonable.
Indeed. I have sometimes made release workflows, hardcoded to the main branch.
You don't want to experiment too much on main because it dirties your commit history with 20 "Fix typo"-esque commits.
Or, if you try to emulate the main branch with a fake main branch (so you can squash it later), you're still going to have some test commits when do the find-replace back to main.
Sometimes forking and using the main branch on the fork (or tags and releases) can help. And if you're on a team, nobody else needs to be aware of the noise that is you throwing trivial changes at the wall.
It gets painful if there are things you've only got on the main repo (e.g. custom runners, credentials, etc.) though.
One tool is to use draft PRs for this - you can run changes to your action YAML from the draft PR. When you are happy just squash the commits as you see fit on a "real" PR to merge the changes in without the mess.
I've found draft PRs for debugging/developing GH action logic to be pretty reasonable.