Closed romanofski closed 6 months ago
It looks like we should be adding the file mode bits in addition to permissions. That seems like an easy change to build_zip.py
Please patch and try https://github.com/bazelbuild/rules_pkg/pull/804. It's not clear if there needs to be a special bit for plain files on Windows too
@aiuto thanks for the quick reply. I'll double check what happens on Windows.
This works for me. Baseline without the patch:
>>> import zipfile
>>> foo = zipfile.ZipFile('test.zip')
>>> foo.infolist()[0]
<ZipInfo filename='.funcignore' compress_type=deflate filemode='?rw-r--r--' file_size=105 compress_size=82>
Then I used a local_override
to grab the patch:
local_path_override(module_name = "rules_pkg", path = "rules_pkg")
Created the zip again and now I get the proper file attributes:
>>> foo = zipfile.ZipFile('test.zip')
>>> foo.infolist()[0]
<ZipInfo filename='.funcignore' compress_type=deflate filemode='-rw-r--r--' file_size=105 compress_size=82>
Disclaimer: I'm not sure whether this is a bug in rules_pkg or really a problem in Azure. However I thought I better file it regardless in case others stumble over this since the "workaround" is easy. So feel free to close.
We're using the packaging rules to package up Azure Function Apps. The mode used to create a
zipfile.ZipInfo
object in the zip file created, causes a broken Azure Function App deployment. The main problem seems to be the file mode which differs significantly when usedzipfile.ZipInfo.from_file
:Env details
OS: GNU/Linux - Ubuntu 22.04 running in WSL2 Python: 3.11.0
Problem description
The
filemode
set with the current code:The
filemode
when the info is constructed withzipfile.ZipInfo.from_file
:You'll notice the
?
at the beginning of the zipinfo for the file if constructed with the current default mode.Reproducer
I can reproduce this 100% with access to deploying a function app. I see if I can file a bug somewhere in Azure too. A minimal reproducer is to create a zip file with the
make_zipinfo
method frombuild_zip.py
using a 16bit? file mode (0o644).Workaround
The workaround I currently use is to set an explicit file mode:
It seems using a 32bit file mode (sorry only stumbled over it in a Stackoverflow post about git file modes is not causing this confusing behaviour in deployment.