ods-core
ods-core copied to clipboard
Restructure ods-core
Is your feature request related to a problem? Please describe. Ods-core has grown massively over the last releases - we should strive for a clean Structure so People quickly find their was thru
Describe the solution you'd like Retructure ods-core into a few functional buckets:
A) Components
- nexus/jenkins/sonarqube/ods*services
-
https://github.com/opendevstack/ods-core/tree/master/jenkins
-
https://github.com/opendevstack/ods-core/tree/master/sonarqube
-
https://github.com/opendevstack/ods-core/tree/master/nexus
-
https://github.com/opendevstack/ods-core/tree/master/ods-document-generation-svc
-
https://github.com/opendevstack/ods-core/tree/master/ods-provisioning-app
B) move jenkins jobs underneath jenkins (https://github.com/opendevstack/ods-core/tree/master/jenkins
/jobs)- away from the root
- https://github.com/opendevstack/ods-core/tree/master/create-projects
- https://github.com/opendevstack/ods-core/tree/master/delete-components
- https://github.com/opendevstack/ods-core/tree/master/delete-projects
C) consolidate scripts
, and and ods-devenv
underneath ods-setup
@michaelsauter thoughts?
Additionally, it always feels weird that the jenkins-agent-base is in ods-core
while all other specific jenkins agents are in ods-quickstarters
. Is there a specific advantage of doing so?
@renedupont This is because ods-quickstarters
is just one repo container quickstarters. It's completely optional -you don't need to use it, you could just use custom quickstarters. However, the Jenkins agent base image should always be used, even by custom quickstarters, as it provides binaries without which the Jenkins Pipeline would fail (e.g. sonar-scanner
). Therefore, the agent base image is part of ods-core
.
Overall, I think consolidating a few things makes sense, but I would refrain from a big restructure. I don't see enough benefit. A couple of points that come to mind:
- I'd merge
ods-setup
intoscripts
. This should be a quick win. - I'd keep the "ods box" related things in its own folder - but it needs to be cleaned up
- I'd probably remove
infrastructure-setup
completely ... maybe just doc what one needs to do in Atlassian to have ODS running. But more and more I consider ODS to be just the OpenShift part, not the Atlassian part. - I'm a bit hesitant to move the
create-projects
,delete-projects
anddelete-components
to Jenkins. For one, because it wouldn't be clear for newcomers that those tasks are executed through Jenkins, so it would be harder to find them underneathjenkins
I believe. Also, those are - in my eyes - super-likely candidates to move to OpenShift Pipelines soon ... maybe we can move them to a folder likepipelines
,admin-jobs
, or something like that. - I'd keep the components on the root level, don't see harm in it. Actually I believe that is the easiest structure to find things ...
Some housekeeping work is always good. I'd start with Michael suggested points and left more refactoring for later on. I assume adding support for openshift 4 will show where more restructuring/refactoring is needed.
@stitakis Initially, OpenShift 4 support will not need to touch anything. Later on when we drop OpenShift 3.11 support and can rethink ODS from an "OpenShift 4 perspective", more things might change.
@michaelsauter thanks for the feedback... did I get it right? Will ODS 4 support OpenShift 3.11 and Openshift 4?
Yes that is the plan, and looks almost certain to be achievable.