filter out shared from yaml anchor output

[lucasyarid]

fixes #131

This PR fixes the github actions changes output when using the proposed shared YAML anchor.
There are unit tests for it but please do propose the correct standards.

[machty]

If I understand correctly, I think it's a bit weird for this logic to be based on the magic keyword "shared", but should rather be based on whether the yaml entry has an & anchor.

In other words it should be possible to have two (or more) different share-able anchored entries that don't trigger a build themselves but can be included as part of other entries.

[lucasyarid]

If I understand correctly, I think it's a bit weird for this logic to be based on the magic keyword "shared", but should rather be based on whether the yaml entry has an & anchor.

In other words it should be possible to have two (or more) different share-able anchored entries that don't trigger a build themselves but can be included as part of other entries.

Agreed, but struggling to find how can I export this data from js-yaml.

[machty]

I'm not sure either (unfortunately don't have time to dig in).

At work we have a pnpm workspace / monorepo and one of the subprojects is called "shared"; even though this wouldn't bite us in our current setup, it's easy to imagine getting bitten by this magic keyword if building a file filter to determine when to run "shared" CI jobs.

[lucasyarid]

@machty doesn't seem possible in js-yaml so we are a bit stuck here.
The only other way I figured is to have another input in the actions passing a list of "shared" keys and TBH this looks overkill and better to just filter outside as you are currently doing.

I'll park this PR awaiting any suggestions but gonna have to eventually close it as I agree filtering just for shared is not the best approach.