6.0.2 breaks previously working `rsync`

[adamlui]

Re-opening unresolved Issue because @ericsciple bizarrely closes it here #2365 (comment)

Are you saying that files are actually missing from the checkout itself? Or is rsync detecting fewer changes than expected?

rsync is detecting fewer changes as a direct result of this bump so it is not resolved

If it's the latter, that would be unrelated to checkout - rsync compares files in two directories, and checkout just puts files on disk.

They are absolutely related, this action is literally creating those files on disk, including the actual timestamps for them for rsync to read

Again, I must reiterate, the only change before bug is this action got bumped, once reverted to 6.0.1 (workflow file remaining unchanged) rsync works perfectly again. It is not my job to hunt for what specific part of the breaking changes you or @TingluoHuang made affected checkout behavior such that rsync can no longer detect timestamps properly (probably git history related)

Closing for now, but please reopen if you have more details indicating the checkout itself produced different files.

Not sure why I would have to provide "more details" for an unfixed bug to remain open, but above was additional info, below is original helpful info:

Here using 6.0.2 https://github.com/adamlui/js-utils/actions/runs/21301896443/job/61321359067

.. it fails to catch a bunch of changed files.

Here using reverted 6 .0.1 https://github.com/adamlui/js-utils/actions/runs/21302606217/job/61323620602

... it gets them all. Workflow file is https://github.com/adamlui/js-utils/blob/0b53ea8be64cf39c9f1005bc04d6f23bd3a66ab7/.github/workflows/sync-minify.js-changes-to-repos.yml

[adamlui]

Also you shouold probably grant permission to re-open within the original Issue itself, otherwise you are makign us bug victims who were completely helpful and did nothing wrong look like we are spamming when unresolved issues are closed and must be re-open.

[adamlui]

All you have to do is observe the commit adamlui/js-utils@26558f0 only changed uses: actions/checkout@v6.0.2 to uses: actions/checkout@v6.0.1 and workflow logs show the unchanged rsync working again (I even link to logs) why would you close it?

[adamlui]

i.e. it doesn't matter if your or Ting think your code is incapable of breaking things, my commit history and logs objectively prove otherwise

[adamlui]

I think whatever you changed messed up the fetch-depth to fail now (was succeeding using fetch-depth: 2 to compare timestamps, typically without it rsync detects no changes even before this bug)

[adamlui]

(I'd look for the fetch-depth logic myself but it's the principle I'm not being paid to fix breaking changes by paid engineers let alone have to fight to keep the bug open)

[adamlui]

Also the fastest (but immoral) way to make me go away is ban me

[ericsciple]

I can't reproduce this.

The changes in v6.0.2 are limited to user-agent string and tag fetching. Nothing changed in how files are checked out.

To investigate further, I need a minimal reproducible example that demonstrates file timestamps differing between v6.0.1 and v6.0.2. Specifically:

1. A workflow that checks out with both versions
2. Shows the timestamp behavior is different between the two versions

There are no other reports of this issue. Without a repro, there's nothing actionable here.

[adamlui]

The changes in v6.0.2 are limited to user-agent string and tag fetching.

There you go it's wrongly fetching the old tags so rsync comparison fails now

To investigate further, I need a minimal reproducible example that demonstrates file timestamps differing between v6.0.1 and v6.0.2

I already linked to the runs above sir why are you doing this?

There are no other reports of this issue. Without a repro, there's nothing actionable here.

Only one person reporting the issue is suffice (me), you failing to emulate does not dictate whether a bug exists.

[adamlui]

...demonstrates file timestamps differing ...

Do you understand it's your paid job not my unpaid obligation to turn on verbose logging and run rsync using each different version of checkout so you can finally understand the timestamps are obviously different? i.e. doing QA is not my job, I am not your paid co-worker but a mere end user doing your employer a favor (report you broke rsync) so put in the time to properly set up env to look at actual timestamps using my exact workflow or don't do it, at least leave the Issue open if you don't wanna work on it beacuse it's not magically going away by ignoring it

[adamlui]

Bottom line the likely culprit is when fetch-depth > 1 it no longer fetches correct prev tags/branches (which you admit is 1 of only 2 changes made)

[adamlui]

If you wanted to reproduce though (which you don't need to if you just follow my guidance, squash the bug at the core) you should edit files in both minify.js/node.js/ and scss-to-css/ to trigger the auto-sync workflows, then when they run simultaneously is when those 2 screenshots were produced (which sometimes causes issues even before this bug, but only now this version causes what you see, changes to docs are unsynced)

[adamlui]

If you pay me though I can do that for you

[adamlui]

It's happening even for 6.0.1 workflows https://github.com/adamlui/js-utils/actions/runs/21642758605/job/62386696961 (misses a bunch of locales + READMEs) vs. https://github.com/adamlui/js-utils/actions/runs/21630706344/job/62342402423 (near identical job, gets them all) so unfortunately this is a larger Actions issue

[adamlui]

I see something good came of this since you actually listened and granted permission to re-open same Issue now. I am re-opening now since I realized it's actually still unresolved and I was just being overly nice but it is still a GitHub issue who is your employer so you're still paid to at least moev to right places because Actions unreliability has been bugging me for years (and unfairly eaten up countless hours of my unpaid time as aresult, I have to constantly re-run failed Workflows to get them to succeed) just you can move it somewhere else if you want but you are all the same frustrating factory to me