-
Notifications
You must be signed in to change notification settings - Fork 695
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 pre and post build hooks #9899
Conversation
f40888c
to
56349de
Compare
c5cd321
to
ed08c4e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs documentation (readthedocs)
when (code /= ExitSuccess) $ do | ||
runBuild |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like it's not really a hook in the original sense anymore, because it causes an internal cabal phase to be skipped entirely. Why?
The way e.g. git hooks are designed is they just augment existing phases. An error code of e.g. a pre-commit hook, will make the commit as a whole fail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could be more explicit in using the exit code to signal whether or not we want the subsequent action to happen or be skipped. You may want the hook to allow skipping under certain conditions.
`catchIO` (\_ -> return (ExitFailure 10)) | ||
when (code /= ExitSuccess) $ do | ||
runBuild | ||
-- not sure, if we want to care about a failed postBuildHook? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I argue we should. The author of the script can always hide errors of whatever commands they're executing inside the hook.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What would you propose?
code <- | ||
rawSystemExitCode | ||
verbosity | ||
(Just srcdir) | ||
(hookDir </> "preBuildHook") | ||
[ (unUnitId $ installedUnitId rpkg) | ||
, (getSymbolicPath srcdir) | ||
, (getSymbolicPath builddir) | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs much more discussion.
- relying on
PATH
to find hooks is very improper imo (I see you already changed it)- this should be in something like
~/.cabal/hooks
and the user should be able to configure the location via the cabal config
- this should be in something like
- just like git, we should only execute hooks if they're marked as executable (windows is a special case, see how we did it in stack as an example)
- we need a discussion what information we want to expose (e.g. env vars that are available to all hooks, like CABAL_VERSION or GHC_VERSION?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PATH
thing has been replaced with looking up ~/.cabal/hooks/.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per the discussion ticket, this now uses a project local cabalHooks
directory.
, (getSymbolicPath srcdir) | ||
, (getSymbolicPath builddir) | ||
] | ||
`catchIO` (\_ -> return (ExitFailure 10)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not convinced we should overwrite the exit code of the script?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is no exit code. This is file not found
mapped to ExitFailure 10
. Yes 10 is just a magic constant.
cabal-install/src/Distribution/Client/ProjectBuilding/UnpackedPackage.hs
Outdated
Show resolved
Hide resolved
5951fc0
to
7f4ea63
Compare
6db998e
to
c99f431
Compare
Preliminary documentation added. |
bb9c361
to
ffa9b5e
Compare
I am not in a huge hurry to merge this. I am especially interested in hearing people's opinions on the "Security Considerations" section in the documentation. |
bc04f49
to
98b6d7f
Compare
The return code of the pre-build hook is not passed as a parameter to the post-build hook. |
33aabe0
to
b5c7050
Compare
b5c7050
to
466e484
Compare
466e484
to
d16ecc3
Compare
Run a program (named "preBuildHook") before doing a package build and another program (named "postBuildHook") after the package is built. The exit code from the pre-build hook is passed to the post-build hook. These programs are project local and need to be in the `cabalHooks` directory which is in the same directory as the `cabal.project` file. Co-authored: Moritz Angermann <[email protected]>
d16ecc3
to
16bd68d
Compare
Rebased against master and doc typo fixed. |
Pretty sure it would not be a good idea to add this. Having the hooks global to the user is a insufficiently flexible (make defining different hook functionality for different projects inconvenient.) Having hooks project local (ie store in git) is dangerous from a security POV. Anyone that gets access to the repo can modify the hooks and insert malicious code. I do not see any solution to this. A single organization may want to implement something like this, but I cannot see this as a good idea for every instance of cabal. |
Run a program (named "preBuildHook") before doing a package build and another program (named "postBuildHook") after the package is built.
These two programs simply need to be on the users $PATH variable and are completely generic.
Co-authored: Moritz Angermann [email protected]
Related to: #9892
Please read Github PR Conventions and then fill in one of these two templates.
Template Α: This PR modifies
cabal
behaviourInclude the following checklist in your PR:
Template Β: This PR does not modify
cabal
behaviour (documentation, tests, refactoring, etc.)Include the following checklist in your PR: