Re: [go-cd] GoCD as an internal customized CI/CD platform

[Ashwanth Kumar]

GoCD server has a well documented API documentation at https://api.gocd.org/current/.

You can build your own interface if interested using that. I should warn you it's not that trivial to do so.

You can look at https://github.com/karmats/gocd-monitor for some inspiration.

Thanks,

On Tue, Jul 5, 2022, 15:01 Young CJ <gored...@gmail.com> wrote:

We noticed that GoCD web page is a Ruby on Rails project. It doesn't  fit well with our team's current teck stack. We want to refactor it with Vue or React. Any good suggestions?

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/becb9a0d-2130-4f81-b449-0689db6567e8n%40googlegroups.com.

[Chad Wilson]

I think GoCD is better described now as a Java / TypeScript / MithrilJS project.

It still includes Rails, running on JRuby, but historically it was a JRuby-on-rails-with-jquery project. Subsequent to that, all of the APIs have been iteratively re-written and migrated to pure Java APIs and there are only a small set of screens left that are server-side rendered within JRuby/Rails (mainly stage details / job details, and IIRC the Value Stream Map). It runs with the latest JRuby version, and a Rails version that only recently went out of support. Migrating to a supported Rails version is something I'd personally like to do (but also without a lot of experience in the area and a lot of time constraint).

The runtime Ruby dependencies within GoCD are also very limited:

As a user, I don't think the internal tech stack should worry you too much, except from a "supply chain security risk" standpoint on dependencies that make up GoCD, or if you are concerned about the community support for GoCD and your ability to take over patching/updating/supporting it if necessary.

If that is the case, it might be useful to understand what you're looking to do with GoCD and the background for your concerns on the tech stack. From a community standpoint, help with further rationalising things, getting rid of legacy JS/rewriting as typescript and migrating more pieces to MithrilJS backed by APIs would be useful though.

If you just want to customise it in some sort of fork based on the existing APIs in ways that the plugin model doesn't support, I suspect you might have an easier path using MithrilJS than trying to introduce yet another framework (sadly there is still some limited Angular 1 in there, I believe only to support rendering of plugin-provided view components).

-Chad

[Young CJ]

Thank you Chad, you help us understand more clearly. 

[Chad Wilson]

No problem.

Ashwanth's opinion is valuable too. It is likely technically possible to run a standalone separate component that communicates over APIs (and GoCD has a great API platform from my perspective), but I imagine should be looked at carefully as likely not an easy undertaking depending on the user experience or type of orchestration you are trying to create :)

-Chad

To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/e000e076-bed3-446c-bfc0-8c6f03103852n%40googlegroups.com.