Configuration of Dockerhub & SVN code repository in Jenkins Pipeline

Question

I am trying to implement CI/CD pipeline for my Spring Boot microservice deployment. Here I am planning to use Kubernetes and Jenkins for that. And I have one on-premise server which I am using for my SVN code repository. I am using SVN for version control. And also for keeping image registry, I am planning to use Dockerhub. I am trying to implement when there is a commit to my SVN code repository, then Jenkins pipeline job need to trigger, compile, test, build, package, build Docker image, pushing to Dockerhub and deploying into Kubernetes cluster.

Here my confusion is that:

1. When I am adding the URL for SVN Dockerhub and credentials, is possible to add these all in my Jenkinsfile ?

The reason for doubt is that, when I am exploring implementation example, YouTube videos are showing checking SCM option in pipeline creation and pasting code repository URL (GITHUB URL) within that. So I am totally confused about whether I need to do like that way or is possible to add Docker Hub and svn url in Jenkinsfile?

2. If adding in Jenkinsfile is not possible, then where I can add my Dockerhub URL and credentials for image pushing and pulling process?

Answer 1

When I am adding the URL for SVN Dockerhub and credentials , Is possible to add these all in my Jenkinsfile ?

Is it possible? Yes. Is it advisable? No. If for no other reason than it makes rotating credentials that much harder, since one would need to update every Jenkinsfile in every project.

You'll want to take advantage of the credential store of Jenkins, and then only consume those credentials in the Jenkinsfile. You may also have good success making use of the pipeline library in Jenkins, to create a new "step" to do the credential binding and interaction with dockerhub and kubernetes.

The advantage to the custom step is that it abstracts away the complexity of doing Jenkins credential lookup, error handling, all that stuff, from the actual projects. The disadvantage of doing that is that it adds opacity, meaning one must ensure the projects know where to find the documentation for that step, and the step needs to be configurable enough for use in all circumstances.