Closed cottsay closed 2 years ago
The createrepo-agent work will require executing commands on the repo host, and since we're enabling exec anyway, we might as well enable it for the ci_archives so that we can sign the checksum files as originally planned.
I remember a discussion in which we talked about running SSH commands out-of-band from the publish-over-ssh plugin. This plugin was de-listed for a time (although I believe it's now reinstated under new maintainers) but it still stores its credentials outside the standard Jenkins credential store.
I think my preference would be to use the Jenkins ssh-agent and credential storage together with an ssh script rather than adding exec configurations to the plugin. I don't have an active reason to distrust the plugin beyond healthy skepticism and a preference for a mechanism I can see versus one I have to audit. I'm interested what you think of that both long-term and immediate term. If using the plugin is more of an expedient in order to get to the really interesting part that is also worth considering.
Looks like ssh-agent
is already getting installed, and we're already populating the required key in the credentials store. Going with that solution requires no changes in deployment :tada:
There is one downside: the ssh-agent
plugin will expose the agent to the entire job, not just a single script section. Docker is supposed to provide us with primary isolation here, but this will remove one layer of secondary isolation.
There is one downside
Looks like the Debian package builds already have this enabled, so adding it to the RPM package builds won't really matter.
So never mind :)
The createrepo-agent work will require executing commands on the repo host, and since we're enabling exec anyway, we might as well enable it for the ci_archives so that we can sign the checksum files as originally planned.