Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Downloaded file contents are incorrect starting with version 1.9 #688

Closed
BelleNottelling opened this issue Feb 3, 2024 · 5 comments
Closed

Comments

@BelleNottelling
Copy link

Describe the bug

After upgrading from version 1.8 to 1.9, we ran into an issue where the translations were no longer working correctly inside of our application. (They are built on a separate repo and then downloaded when building the main app)

The hash of the file I am checking when downloaded (and extracted) through v1.8 is 03BFCE70E15EDC39B775E673B5E03FB2F71DAC16A216C4AB5A3803D8F36CE11E.

When using the same config and using v 1.9, the resulting hash is 0BB2FCC4A185967658AE3D3172E80CC713212659BB59DD8884EF193E336F238C.

To Reproduce
Steps to reproduce the behavior:

  1. Download our latest translation release via version 1.8 and have it be extracted.
  2. Then do the same with version 1.9.
  3. Select the same file in both. You should specifically be comparing any of the .mo files as those are what we are having issues with.
  4. Compare the hash of the selected files, they will be different.

I really don't understand where this issue could be coming from, but it's certainly causing us issues

@me-axentia
Copy link

I have a similar experience. Our CI workflow fails when upgrading to version 1.9.
We download a .zip with just one file and extract it. But somehow it appears that the extracted file does not have the correct content.

@heinrich-ulbricht
Copy link

I did not double check but I also got trouble with downloaded and unzipped contents. Will check further and watch this issue.

@heinrich-ulbricht
Copy link

I can confirm that the new version 1.9 breaks files. Reverting to 1.8 solves this. That's a bit unnerving.

@BelleNottelling
Copy link
Author

That's a bit unnerving.

Indeed, we have now since replaced the action with shell commands so that we don't need to worry about extraction unexpectedly breaking

@robinraju
Copy link
Owner

Apologies for the late response. A new release with a fix for this issue is now available. Please test this and let me know if it fixes it.

The issue was caused after upgrading the node runtime to v20, and the library used to extract zip files broke the functionality.

- uses: robinraju/release-downloader@v1.10
  with:
    fileName: "foo.zip"
    latest: true
    extract: true

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants