chocolatey-community / chocolatey-hooks

Chocolatey Community managed repository for hook packages.
https://docs.chocolatey.org/en-us/features/hook
Apache License 2.0
1 stars 7 forks source link

(#9) Adds Jenkins-Set-Prefix Hook Package #10

Closed JPRuskin closed 2 months ago

JPRuskin commented 1 year ago

Due to the way Jenkins' MSI installs, changes to the Jenkins.xml configuration file can be unset (though backed up).

This hook sets the Prefix value after every installation of Jenkins, ensuring that paths won't break unexpectedly.

There is a parameter (/prefix) that can be passed to set the path you want, though it defaults to jenkins (e.g. accessing Jenkins via yoursitehere.local/jenkins).

I considered having a blank default, and removing the prefix if you didn't provide one, but decided that anyone who ran choco install jenkins-set-prefix.hook probably did want a prefix of some kind.

Additional consideration: Should this run the same logic on install, such that people can use it to set a prefix on an already installed Jenkins instance without running choco install jenkins --force (or waiting for an upgrade)? If so, I'd split bits into a function file. This would be, I think, similar to how post-install-all packages end up running their own logic, so seems somewhat supported already.

JPRuskin commented 1 year ago

I've just spotted @TheCakeIsNaOH's comments on #8, around package parameters. I think my implementation here is okay (we don't use any parameters during the hook, just during install, and it's locked to the Jenkins package rather than all), but I possibly need to consider this further.

steviecoaster commented 1 year ago

There's a bit more to unpack here in thinking about it a little more. You'll need to make this a dependency on the jenkins package to ensure it gets picked up, and subsequently fired off.

And since there will be a change to the jenkins package to make that work, it seems that we could drop the use of a text file here and just pick up $env:ChocolateyPackageParameters in the hook script itself, and do the right things from there. 🤔

AdmiringWorm commented 1 year ago

There's a bit more to unpack here in thinking about it a little more. You'll need to make this a dependency on the jenkins package to ensure it gets picked up, and subsequently fired off.

Don't do this at the moment, while it is fine for internal packages to have a dependency on hook package, we have had talks before that it may not be something we will allow on the community repository as it could potentially open up the user to have something being done on their computer that they have no idea of.

steviecoaster commented 1 year ago

There's a bit more to unpack here in thinking about it a little more. You'll need to make this a dependency on the jenkins package to ensure it gets picked up, and subsequently fired off.

Don't do this at the moment, while it is fine for internal packages to have a dependency on hook package, we have had talks before that it may not be something we will allow on the community repository as it could potentially open up the user to have something being done on their computer that they have no idea of.

You're right. I forgot about this conversation! Thanks for that!