search

rht-labs / labs-ci-cd

👻UNMAINTAINED - A collection of Red Hat Open Innovation Labs CI/CD components
Apache License 2.0
101 stars 70 forks source link

Consolidate Template Repos #12

Closed sherl0cks closed 6 years ago

sherl0cks commented 6 years ago

We have https://github.com/rht-labs/openshift-templates. Can that be the home for templates, and the we reference them from here?

InfoSec812 commented 6 years ago

Seems like a lot of extra hoops to jump through every time we want to make a change, but I suppose we can if it is required.

sherl0cks commented 6 years ago

@InfoSec812 that is a fair point. It would be nice to have one less repository to jump between. At minimum, we need consolidation. we have the same thing in two places, and that's not good. @oybed is interested in having the automation in this repo point to remote files. I just want a single source of truth, whatever it is.

mdanter commented 6 years ago

My vote is on a single repo, this one, instead of the templates one. I'm also using this one to add more templates to it.

sherl0cks commented 6 years ago

OK - I'm going to open a PR that merges https://github.com/rht-labs/openshift-templates here

mdanter commented 6 years ago

🤗

oybed commented 6 years ago

I'm totally fine with consolidating and merging the ones from openshift-templates into this repo to avoid having duplicates.

My points were the following: 1) labs-ci-cd should be CI/CD related, so it doesn't make sense to add content that aren't related to CI/CD. Hence, we need to find a home for templates that currently don't have a home, but again I don't want to see everything just dumped into this repo. The openshift-templates may be a good one to catch these other ones, or maybe there's a specific repo per implementation if that make sense. 2) The openshift-applier supports both local and remote files. If the labs-ci-cd only uses local files (i.e.: referenced as part of the local inventory), chances are that consumers of the labs-ci-cd repo also just copies everything as-is and keep local copies in their own repo. The latter is fine, of course, if it's done on purpose (i.e: upstream github is not accessible, or some additional tweaks are needed), but also unnecessary in those cases where the "upstream" template can be referenced.

sherl0cks commented 6 years ago

@oybed that makes sense. My apologies if in my brevity I didn't represent you fairly. I believe #14 meets the requirements you've outlined here. A few other thoughts:

  1. Agreed, though I must say I'm struggling to think of a template we would build & maintain that DOES NOT fall under an application centric CI/CD umbrella. The only thing I can think of is a generic user/group/role template e.g. setting up a Dev group. I don't think this will be a tough requirement to meet, but it's good to make explicit.
  2. This is a good point with which I agree fully, and it really gets into process more than technology. Although, working with #8 and some simple getting started tooling could accelerate this behavior.