-
Notifications
You must be signed in to change notification settings - Fork 98
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
[Bug] Set file mode explicitly for regular files #1323
Conversation
✅ Deploy Preview for nginx-gateway-fabric ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Please update your main commit message to contain the basic problem/solution as defined in your PR description. |
Could you also create an associated bug to track and close with this PR? |
Would you mind providing more details? Most open-source projects in which I have maintained/contributed squashed commits from a PR into a single commit and written the messages there. I am not sure how does NGINX community works. In my understanding, you ask me to squash the commits manually and write the commit message: # Step 1: Reset the 2 commits in this PR
git reset HEAD^^
# Step 2:
git add ${ALL_FILES_GOT_RESET}
# Step 3: Write commit message here
git commit
# Step 4:
git push -f ... Is my understanding correct?
I have already opened an issue #1328. |
Yes, we can supply the commit message when squashing on a merge. However, it makes it easier for us when reviewing to know what changes are going into each commit. "update" doesn't tell us anything useful about the changes that were made in that commit. It also saves us the step of copying the PR description into the squashed commit message because it'll already be there if you have that commit message to start with. You don't have to squash the commits manually, but the first commit should at least have a useful message (likely matching your PR description). |
You can also squash or change a commit message by doing |
* As shown in the following code snippet, the function `ensureFiles` checks the file mode for both regular files and secret files. https://github.com/nginxinc/nginx-gateway-fabric/blob/6d4cfd7f0de32e9f98dae358cb6cec93529109a5/internal/mode/static/nginx/file/manager_test.go#L43-L47 * The function `ReplaceFiles` in `nginx/file/manager.go` creates files by internally calling [os.Create](https://pkg.go.dev/os#Create), which, by default, creates files with mode 0666 (before applying `umask`). See the [source code](https://github.com/golang/go/blob/de5b418bea70aaf27de1f47e9b5813940d1e15a4/src/os/file.go#L357-L364) of `os.Create` for more details. * The function `writeFile` changes the mode of secret files to 0640 by calling `chmod`, but does nothing for regular files. Hence, the check `Expect(info.Mode()).To(Equal(os.FileMode(0o644))) ` in `nginx/file/manager_test.go` only passes for `umask` with specific values. * In my environment, the `umask` value is 002. Therefore, the mode for regular files will be 0666 - 0002 = 0664, causing the unit test to fail. In the following screenshot, 420 is 0o644, and 436 is 0o664. ![Screen Shot 2023-12-02 at 6 05 36 PM](https://github.com/nginxinc/nginx-gateway-fabric/assets/20109646/b621c7de-2465-4c5a-988b-4cf625e5dca7) * Solution: This PR sets the file mode explicitly.
72282d7
to
3450cdd
Compare
Thank you for the explanation! It's a bit embarrassing, but this is the first time I've learned how to write long commit messages locally lol. I have already updated the PR. |
Proposed changes
As shown in the following code snippet, the function
ensureFiles
checks the file mode for both regular files and secret files.nginx-gateway-fabric/internal/mode/static/nginx/file/manager_test.go
Lines 43 to 47 in 6d4cfd7
The function
ReplaceFiles
innginx/file/manager.go
creates files by internally calling os.Create, which, by default, creates files with mode 0666 (before applyingumask
). See the source code ofos.Create
for more details.The function
writeFile
changes the mode of secret files to 0640 by callingchmod
, but does nothing for regular files. Hence, the checkExpect(info.Mode()).To(Equal(os.FileMode(0o644)))
innginx/file/manager_test.go
only passes forumask
with specific values.In my environment, the
umask
value is 002. Therefore, the mode for regular files will be 0666 - 0002 = 0664, causing the unit test to fail. In the following screenshot, 420 is 0o644, and 436 is 0o664.Solution: This PR sets the file mode explicitly.
Checklist
Closes #1328
Before creating a PR, run through this checklist and mark each as complete.
make unit-test
locally.