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

Add check on project root file and fail if broken link #10103

Merged
merged 4 commits into from
Aug 26, 2024

Conversation

albertodvp
Copy link
Collaborator

@albertodvp albertodvp commented Jun 11, 2024

This PR modifies behaviour or interface**

Include the following checklist in your PR:

QA Notes

Build patched version

cabal build cabal-install
alias patchedCabal=$(cabal list-bin cabal-install)

Reproduce

Not patched version

cd "$(mktemp --directory)"
cabal init --exe --simple
ln -s I-do-not-exist cabal.project
cabal build

Expected behavour: cabal ignores the broken link and builds the project (ignoring the cabal.project and not signaling anything)

Patched version

Then, slighly adapting the example provided in the issue

cd "$(mktemp --directory)"
patchedCabal init --exe --simple
ln -s I-do-not-exist cabal.project
patchedCabal build

Expected behavour: cabal should exit with status code 1 and should print:

The given project file 'cabal.project' is broken. Is it a broken symbolic link?

Resolves #9937

@ffaf1 ffaf1 added the attention: needs-manual-qa PR is destined for manual QA label Jun 12, 2024
@albertodvp
Copy link
Collaborator Author

I don't think it's particularly valuable to add a changelog for this, but let me know if you think otherwise

@geekosaur
Copy link
Collaborator

It's still a user-visible change, and entirely possible that someone relies on the old behavior (granting that that's relying on a bug, but https://xkcd.com/1172/).

@jasagredo
Copy link
Collaborator

Confirmed working on Windows:

CMD> mklink cabal.project I-do-not-exist
symbolic link created for cabal.project <<===>> I-do-not-exist
➜ rm I-do-not-exist
➜ ls -lah cabal.project
lrwxrwxrwx 1 Javier Javier 4 Jul 22 23:53 cabal.project -> I-do-not-exist
➜ $CABAL build
Warning: this is a debug build of cabal-install with assertions enabled.
The given project file 'cabal.project' is broken. Is it a broken symbolic link?

@jasagredo jasagredo added the tested-on: windows QA has been successful on Windows label Jul 22, 2024
@albertodvp
Copy link
Collaborator Author

This is my first PR on Cabal, and I'm not sure how the process works (I couldn't find any information in the CONTRIBUTING file). Should I rebase it periodically? Am I missing anything to get this PR reviewed?

@ulysses4ever
Copy link
Collaborator

Hey @albertodvp! I'm sorry you had to wait for so long. Don't worry about rebasing. We just need to get around to reviewing your PR: two approvals are necessary. I prodded people on Matrix, so, hopefully, this can be done this or next week. After two approvals we'll see how to proceed.

@jasagredo
Copy link
Collaborator

jasagredo commented Jul 25, 2024

Usually the attention: needs-review label is enough, but PRs sometimes get stuck there. My suggestion would be:

  • Rebase the feature on top of master.
  • Seems you were in the process of adding tests? or were you just fixing those cabal.project files (were they broken?)?
  • I would suggest adding a test in any case.
  • Hopefully someone will come and review the PR, otherwise you can ask in the Matrix channel.

@albertodvp
Copy link
Collaborator Author

Thank you!

I did add some tests, I'm happy to add others if you have some requests ☺️

Copy link
Collaborator

@geekosaur geekosaur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Little things.

Strictly speaking, this is a race condition. It doesn't really matter in this case, though; you just gets suboptimal messaging.

let isUsableAciton =
handle @IOException
-- NOTE: if any IOException is raised, we assume the file does not exist.
-- That is what happen when we call @pathIsSymbolicLink@ on an @FilePath@ that does not exist.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
-- That is what happen when we call @pathIsSymbolicLink@ on an @FilePath@ that does not exist.
-- That is what happen when we call @pathIsSymbolicLink@ on a @FilePath@ that does not exist.

-- That is what happen when we call @pathIsSymbolicLink@ on an @FilePath@ that does not exist.
(const $ pure False)
((||) <$> pathIsSymbolicLink filePath <*> doesPathExist filePath)
isUnusable <- isUsableAciton
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
isUnusable <- isUsableAciton
isUnusable <- isUsableAction

if exists
then return ProjectRootUsabilityPresentAndUsable
else do
let isUsableAciton =
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
let isUsableAciton =
let isUsableAction =

@albertodvp
Copy link
Collaborator Author

Little things.

Strictly speaking, this is a race condition. It doesn't really matter in this case, though; you just gets suboptimal messaging.

Thank you for the review!
Could you please help me see where I've introduced a race condition?

@geekosaur
Copy link
Collaborator

It's the very concept: checking something before use instead of at the time of use; in this case, that would be reporting why opening the project file in one of the withProject… etc. functions failed. (Look up "TOCTOU" in a search engine.)

Copy link
Collaborator

@ulysses4ever ulysses4ever left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect, thanks!

@ulysses4ever
Copy link
Collaborator

The next step would be setting a merge label when the author is happy with the PR and there are no lingering discussions.

@albertodvp albertodvp added the squash+merge me Tell Mergify Bot to squash-merge label Jul 25, 2024
@mergify mergify bot added the merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days label Jul 27, 2024
@albertodvp albertodvp removed the squash+merge me Tell Mergify Bot to squash-merge label Jul 29, 2024
@geekosaur geekosaur removed the merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days label Aug 22, 2024
@albertodvp albertodvp force-pushed the master branch 2 times, most recently from 9fe7e37 to f4fbcf4 Compare August 22, 2024 19:18
@albertodvp albertodvp added the squash+merge me Tell Mergify Bot to squash-merge label Aug 23, 2024
@mergify mergify bot added the merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days label Aug 25, 2024
@geekosaur
Copy link
Collaborator

"Pull request #10103 has been removed from the queue squash-merge: The pull request cannot be checked because of an incompatibility with branch protections.". Help?

(I thought this might be a problem with #10260 at first, but (a) we've had successful merges since then (b) Mergify's log says this also happened on 27 July which was well before #10260.)

@mergify mergify bot merged commit 4f01b76 into haskell:master Aug 26, 2024
50 checks passed
@albertodvp
Copy link
Collaborator Author

Hi @geekosaur - I've just rebased and force-pushed. I hope that was ok

@geekosaur
Copy link
Collaborator

Yes, that's fine and probably what it needed. Mergify's been being a bit weird of late for some reason; it doesn't like something that's in master that it's failing to rebase on itself, but manual rebases seem to un-stick it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
attention: needs-manual-qa PR is destined for manual QA cabal-install: other merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days re: project-file Concerning cabal.project files squash+merge me Tell Mergify Bot to squash-merge tested-on: windows QA has been successful on Windows
Projects
Status: To Test
Development

Successfully merging this pull request may close these issues.

broken symlinks for configuration files are silently ignored
6 participants