Do not use self-signed certificates for your SCM
A self-signed certificate requires that users (and consuming systems) reduce their trust in that system by either using special cases (installing the self-signed certificate on every consuming system) or by reducing the strength of the security of the system (skipping SSL verification, etc.).
While users are waiting for the SCM server (e.g GitHub Enterprise, Bitbucket Server, …) to have an SSL certificate issued, they should switch to use ssh based communication with the SCM server. That is done by using an ssh protocol URL to the server, rather than an https protocol URL. For example, instead of: https://github.example.com/user/repo they would usegit@github.example.com:user/repo.git
The ssh protocol is secure and does not require that the customer install a certificate on the SCM Server.
Triggers: Polling must die
Builds Periodically triggers builds as per the schedule (every 10 minutes) even if you haven’t changed anything. Poll SCM will check for changes before triggering any build, if there are changes to the previous version there only build will be triggered.
Builds Periodically is not recommended. Then Poll SCM is not the best practice but Webhooks . Please read the post “polling must die” to have more background context.
You can run this groovy script to see if there is any job in Jenkins configured to use Polling. The groovy script is run from the Jenkins Script Console ($JENKINS_URL/script).
The following articles will walk you through WebHooks:
Shallow clone
Perform shallow clone, so that git will not download history of the project, saving time and disk space when you just want to access the latest version of a repository.
0 Comments