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

[JPRuskin]

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]

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]

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]

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]

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!

[TheCakeIsNaOH]

Instead of storing the value in the hook folder, this probably should be moved to the config, and accessed with Get-ChocolateyConfigValue.
chocolatey/choco#2854

[JPRuskin]

I'd agree, but I don't think that'll be included in Chocolatey until 2.0/2.1.

Would it be acceptable to add a function file (as I'm currently starting to do) and then write something similar to:

if (-not (Get-Command Get-ChocolateyConfigValue)) {
    <#Define a function that replicates this sort of thing #> 
}

That way, we can provide support for v1 and v2. Alternatively, I'll ask Gary if he thinks we'll be able to backport that functionality - but that may be unlikely, to be honest.

I'll also say that, though I prefer the idea of a single solution for all packages, I feel slightly odd storing this value in a Chocolatey config. :\ That's probably all my fault, though! :)

I could, of course, also write this for v>2.0 and then just publish my 1.0 compatible version privately - but it will be a bit of a shame to limit it to an unreleased version already! I was looking forward to providing another example to this repository (but, at the same time, no point in making a bad example!).

[pauby]

we'll be able to backport that functionality - but that may be unlikely, to be honest.

That's not something we will be doing.

[TheCakeIsNaOH]

Would it be acceptable to add a function file (as I'm currently starting to do) and then write something similar to:

That would work on a technical level, as far as I'm aware. I personally prefer not to do this, and instead focus on getting helpers in Chocolatey CLI or in an .extension.

But I'm only one of the maintainers of this repository, so I'm happy for other viewpoints.

I'll also say that, though I prefer the idea of a single solution for all packages, I feel slightly odd storing this value in a Chocolatey config

It is a bit weird, from what it is currently used for, but according to Gary, it was always intended to hold more information.

One advantage is that the chocolatey config file already has ChocolateyGUI integration.

[JPRuskin]

So, I waited to try and integrate this with the PR (now it's been released as part of 2.1), but after trying it and discussing it with Gary I realise that it's still unready for package-level variables (even if I didn't want to support 1.*).
We need to discuss and work on it internally, so for now I'll not use it here - but I'm getting requests for this hook package to be more publicly available.

Based on your preference, I'm happy to either:

• Continue PRing the hook package to this repository, and update it when we have agreement on exactly what's going on with package-config-in-config or
• Move it to my own repository, and look at moving it back when we can make it a great example package

Which do you prefer?

[pauby]

Remember that for customers, we continue to support 1.x. Whether the use case for this is not customers using 1.x or not is a different question.

Is this solution not for customers using QSH / C4BAE? If that is the case, I'm unsure here is the best place for it.