bkendall
commented
2 years ago Looks like the internal hashing cache isn't detecting the change. Wonder why that is... I'll take a look
Closed Miodec closed 2 years ago
bkendall
commented
2 years ago Looks like the internal hashing cache isn't detecting the change. Wonder why that is... I'll take a look
bkendall
commented
2 years ago So ultimately, it's because the hash/cache mechanism uses mtime (modified time) as a parameter when checking if a file changed and it should be re-hashed (and that hash, cached). If the cached hash value we have for the modified time of the file matches what the filesystem reports, we'll use the cached value. (if that was clear... well, that confused me writing it)
For whatever reason, when your script updates the contents of the file, the mtime of the file itself isn't being updated. That's breaking the caching behavior (breaking the assumptions it makes, anyway).
The quickest workaround is to remove the output folder/files before running gulp - that'll guarantee that the files get new modified times. But it will slow down the deploy just a tiny, tiny bit (unless you're using many, like 1e5+ files)
bkendall
commented
2 years ago Yeah, looks like this is an expected behavior from Gulp: https://gulpjs.com/docs/en/api/dest#metadata-updates
I'm not sure after some quick searching what the answer should be, but removing the destination files/folders before running this particular task would fix the deploy path. But, the CLI is working as intended in this scenario.
Miodec
commented
2 years ago Ah i see - interesting. Thanks for having a look.
Have you thought about my small suggestion? Adding a message along the lines of "no files uploaded" if no files actually got uploaded?
bkendall
commented
2 years ago It's something to consider - I'll run it by the team and see what they say. Thanks for the suggestion!
Miodec
commented
2 years ago Thanks for considering.
A short update: I have added clean task to my gulpfile
const del = require("del");
task("clean", function () {
return del('dist/**', {force:true});
});Sadly this does not fix the issue, weirdly enough the file still shows that it was last modified yesterday.
I guess I will have to keep digging.
Miodec
commented
2 years ago Alright, found a solution. For anyone finding this in the future: https://github.com/dlmanning/gulp-sass/issues/706#issuecomment-421130305
[REQUIRED] Environment info
firebase-tools: 10.1.2
Platform: macOS 12.1
[REQUIRED] Test case
Files required:
task("test", function () { return src(["static/sw.js"]) .pipe( replace( /const staticCacheName = .*;/g,
const staticCacheName = "${Date.now()}";) ) .pipe(dest("./public/")); });[REQUIRED] Steps to reproduce
npx gulp testfirebase deploy --only hosting[REQUIRED] Expected behavior
The file will be uploaded.
[REQUIRED] Actual behavior
The file is not uploaded.
Comments
I think its worth noting that if after the gulpfile task I manually save the file, the upload works.
The command output also confusingly displays
file upload complete.Also weirdly enough the
populate queuestep displayssuccess: 1, but the next step displays 0 uploads queued.I think in this case the message should be
upload complete. No files uploaded. It took me a few hours of troubleshooting to even realise the file is not even uploaded. I was looking through browsers caches, CF caches.Full deploy output: