@akilan there’s nothing special toward implementing a build for a node stack. For all practical purposes, a GoCD agent will just run shell commands non-interactively, with a relatively blank environment (I say relatively because GoCD will set some GoCD specific variables for your usage that shouldn’t affect your build as they are namespaced).
So theoretically you should be able to run your npm commands as you normally would, given that node is installed and you run non install before all other steps in your build to ensure dependencies are installed.
npm install - damned autocorrect :smile:
The documentation implies that a pipeline with p4 material with autoUpdate=false will use the #head revision:
"...Instead it will check for changes only when you trigger a pipeline that contains this material."
It seems to be syncing to a specific older revision, though. Has anybody seen something similar?
**/* I believe.
@migsss as @mythgarr said, you can configure GoCD to recognize patterns as Jira links. Not sure what other specific integrations with such things you are referring to. Here’s the link to the docs on how to set up link matching with Jira: https://docs.gocd.org/current/integration/
For what it’s worth, git is not an Atlassian tool. It’s an SCM for which GoCD has full support. Bitbucket is an Atlassian service that provides git repositories.
You can run GoCD on GCP. It’s just a Java app. You could provision it on 64bit Linux instances (server + agents)
@migsss I don’t know anything about what your build is or what you’re trying to do? I can tell you that both GoCD and Jenkins are, at the core, command runners, so you ought to be able to achieve what you want in GoCD whatever you're doing in Jenkins right now.
I’m trying to understand what you are asking here:
can i integrate current integration that we have in jenkins on Go CD software? i read that Go CD mainly focuses on delivery, while on the other hand jenkins is more on the integration
I think some of the terminology around continuous integration (CI) vs continuous delivery (CD) might be confusing you. Continuous delivery processes require that your team already adopt continuous integration processes. You can sort of think of continuous delivery as a more advanced evolution of continuous integration. I suggest you read more about CI and CD to get a better understanding. Explaining these approaches here is beyond the scope of this channel and could be an easy google search. That said, the fact that pipelines and such are first-class concepts in GoCD make it a better tool than Jenkins for teams wanting to go beyond continuous integration to achieve continuous delivery.
Before I continue, a disclaimer: I’m a core developer for GoCD, so I clearly favor this tool.
The big takeaway/differentiator from Jenkins is that GoCD allows you to model complex workflows via build pipelines quite easily. Pipelines (both independent as well as upstream/downstream dependent), stages, artifact promotion are first-class concepts in GoCD. In my opinion, the same feat is much more clumsy and difficult in Jenkins. I would argue that any workflow that one can model in Jenkins can be modeled in GoCD, and probably more elegantly.
