Does GitLab CI/CD provide any built-in or out of the box jobs/scripts that can be configured similar to Jenkins Plugins or Azure DevOps Build and Release Tasks?
I think it’s a really powerful feature to have for any CI/CD platform to have and it can really bring down the pipeline design or development time.
Below are links to the Jenkins Plugins and Azure DevOps Build and Release tasks.
Jenkins:
Azure DevOps:
I was trying to find a built-in plugin in auto devops that allows me to run/invoke shell scripts on a set of different remote linux servers. do you know how can this done using auto devops?
I would be very surprised if AutoDevops can do that. You probably want to write your own .gitlab-ci.yml file and if you want to limit which scripts run on which servers, to might want to use tags.
Since I worked on Azure DevOps in one my previous roles, I can’t stop myself comparing between the 2 platforms. I am now working exclusively working on GitLab.
So, running the remote scripts using SSH can be easily done in Azure DevOps using built-in SSH task which can be configured using GUI or YAML.
It looks like GitLab Auto DevOps doesn’t have this feature yet unless I am missing anything.
But it’s a very powerful feature to have especially the GUI. Hoping GitLab will include these features in their future updates.
The main “plugin” system for GitLab CI is the use of Docker images combined with the include feature that makes it easy to use the same pipelines for many different projects.
GitLab’s CI is quite different in that respect, and I’d argue more it’s more powerful and the better for it. But it does also mean that it’s definitely in the low-code model, not no-code. There isn’t a gui to fill in the blanks.
Now, for just executing something on a remote system, you do have options. If you want to ssh directly in, all you need is a docker image with ssh-agent and ssh installed, load put the private key into a CI variable, and in your job fire up agent, load your key into agent, then ssh away.
Something like this:
mkdir -p ~/.ssh && echo "$GITLAB_KNOWN_HOSTS" >> ~/.ssh/known_hosts && chmod 600 ~/.ssh/known_hosts
eval $(ssh-agent -s)
echo "$SSH_DEPLOY_KEY" | tr -d '\r' | ssh-add -
ssh my-host echo hello world
Alternatively, you can install the gitlab agent on your destination machine and let gitlab itself do the plumbing to allow the script section of your job to run directly on your deployment host.
This is great information. Thank you for sharing.
There is one more feature in Azure DevOps which I forgot to mention earlier. Azure DevOps has a “Market Place” feature where ready made plugins are available for different platforms.
For example, if your target deployment platform is IBM WebSphere or IIS or Tomcat or AWS or Google Cloud and etc, there will be a built-in plugin available in the market place which you can use out of the box and integrate it into your CI/CD pipeline.
These plugins are either created by product vendors or third party developers and certified my Microsoft. There are also plugins which are not certified by Microsoft. You can directly integrate and configure these plugins into your CI/CD pipeline either in a GUI fashion or using YAML.
I think Jenkins also something similar.
I personally find this “Market Place” feature really powerful and time saving. I am not sure if there is something similar available for GitLab CI/CD at the moment.
Here is the link to the Azure DevOps Market Place.
https://marketplace.visualstudio.com/azuredevops/
Here is the link to the Jenkins Plugins Market Place
I personally find this “Market Place” feature really powerful and time saving. I am not sure if there is something similar available for GitLab CI/CD at the moment.
I think the NPM people learn about the risks of a bazaar of ad-hoc stuff no one validates, about once a quarter. Please be careful, and spend that extra time doing your own validation.
Right, there is no gui config.
But I think you’re missing the real power of leveraging containerized runner. You see, you can pick literally any image you want and use that to run your CI steps.
So, for Websphere, write a ci job that uses the official Websphere image and does your deployment.
In this model, you are using only officially supported first-class components, your pipeline artifacts, and a few lines of script. Much more powerful, maintainable, and trustworthy than a third-party plugin model.
Most of the “Market Place” plugins provided by Azure DevOps is either directly from the Product Vendor or Validated by Microsoft.
@hstenzel azure devops runners known as agents can also be containerized along with their dependencies. I think we could probably do the same with Jenkins runners or agents. I have still ways to go to understand the power of gitlab. But as far as the gui goes, azure devops has made significant strides. I think gitlab has released some new gui features in their recent versions. so they are on the right path. hopefully they may come up with their own “market place” feature soon.
Well then that’s a no for me, and anyone harmed by the DRDos incident.