Adding postgresql-evr to Jenkins slaves

I’m looking to get the postgresql-evr RPM installed on the Jenkins slaves so Katello tests can use it. What is the process for doing so? Alternatively, is installing postgresql-evr something that can happen during test time?

I don’t know too much about how the test pipeline works, but I’m curious what might have to happen when a new version of postgresql-evr is released. Will supporting multiple postgresql-evr versions for different versions of Katello be an issue?

The way we currently test, I anticipate this would be an issue. Do your forsee this happening with this plugin? Revving enough and varying enough to need to test it across different versions?

I don’t envision postgresql-evr to be needing many revisions, but is it the case where one revision is already too much? I suppose it would be okay if we can maintain backwards compatibility. Looks like this is also going to be an issue for postgresql-debversion.

Yeah, the only really way we plan to use it is going to be:

  • Creating a column of this custom type
  • calling a function within a few triggers to populate that column
  • Sorting by that column

The only update i could see is that if we found a bug within the functions or type definition itself, which seems like it could be resolved independent of the application. So i don’t see many updates to this, and if there are i imagine they would be fairly early into our implementation of it, and backwards compatible.

BUMP, i believe we answered the raised questions, how do we go about
getting it added?

any update to this?


You’d open a PR to add it here ( You’ll likely need to add configuration of the right repositories to init.pp.

I would like to avoid adding the regular Foreman repositories to all our slaves. Does it make sense to create a small infra yum repo for this?

We’d only be adding the Katello repository if that helps at all. I’d prefer to avoid a lot of overhead where possible.

IMHO the issue is still that you have to pick one release and ship that, potentially pulling in other things you don’t want.

On a related note: what are going to be the instructions for users who have deployed external PostgreSQL servers in their production envs? Install the Katello repo on your DB server(s)?

Nightly could be that version.

yes, or just install the extension package manually.

I’m not opposed to an infra repo, but i dont have a strong opinion either way

We do this with CentOS and EPEL, SCLs. I am not seeing how our own repositories are suspect. I just wanted simple path. Now we need:

  • comps
  • hosting
  • jobs to generate the infra repo
  • rules around when we generate it

If we have other use cases for this I would be more in favor. @pcreech I am thinking to your investigations in pungi if this would be a secondary use case enough to bolster going that route.

So, from what I can gather, it seems there is enough cross-functional needs to provide non-standard packages (stuff not in base repos ) to support overall infrastructure efforts.

Many infrastructures do this. I know for a fact a lot of fedora/centos infra have custom built bits to support their environments.

With that, I think we’re at the point where we need to start working the direction of a standalone “infra” repo that we can build/tag packages into to distribute across our infrastrucutre.