Jenkins Build Triggers

자동화의 기본. 내가 원하는 때에, 빌드 진행하기.

지금 어떤 방식으로 사용하고 있는지는 ex) 로 기입 해놓았습니다.

 

파라미터가 필요하다면, Default Value에 값을 넣어줘야한다.

예를들어 브랜치 파라미터가 필요하다면, 어떤 브랜치를 기본으로 할지 정해놓아야한다. 비어있으면, 값이 없는상태로 빌드가 진행된다.

 

젠킨스에서는 Build Triggers를 통해 여러가지 방식으로 언제 빌드를 할지 정할 수 있다.

 

Trigger builds remotely (e.g., from scripts)

빌드를 원격으로 유발 ( 예 : 스크립트 )

미리 정의된 URL을 사용해서 원격으로 빌드를 진행할 수 있다. 

Enable this option if you would like to trigger new builds by accessing a special predefined URL (convenient for scripts).
One typical example for this feature would be to trigger new build from the source control system's hook script, when somebody has just committed a change into the repository, or from a script that parses your source control email notifications.

You'll need to provide an authorization token in the form of a string so that only those who know it would be able to remotely trigger this project's builds.

This is most useful when your Jenkins instance grants read access to this job to anonymous users.

When that's not the case, Jenkins will reject requests sent to the trigger URL even when the correct token is specified.

To solve this, the HTTP requests needs to be authenticated as a user with the necessary read permission for the job — but then you could probably just grant this user the permission to build this anyway.

Another option is to use the Build Token Root Plugin, that provides additional URL endpoints to trigger builds using this token, and doesn't require the otherwise necessary Overall/Read and Job/Read permissions to do so.

 

Build after other projects are built

다른 프로젝트 빌드 후 빌드

다른 job에서 빌드 후 진행해야할 프로젝트로도 지정 할 수 있다. 빌드의 성공유무에 따라 빌드 여부를 정할 수 있다.

Set up a trigger so that when some other projects finish building, a new build is scheduled for this project. This is convenient for running an extensive test after a build is complete, for example.

This configuration complements the "Build other projects" section in the "Post-build Actions" of an upstream project, but is preferable when you want to configure the downstream project.

 

 

 

Build periodically

시간 기준 트리거

제일 기본적인 예약법. 스케줄링에는 cron 표현식을 사용한다

ex) 젠킨스 백업(매일 12시), 프로젝트 정적 분석(월요일 오전 7시마다) 

Provides a cron-like feature to periodically execute this project.
This feature is primarily for using Jenkins as a cron replacement, and it is not ideal for continuously building software projects. When people first start continuous integration, they are often so used to the idea of regularly scheduled builds like nightly/weekly that they use this feature. However, the point of continuous integration is to start a build as soon as a change is made, to provide a quick feedback to the change. To do that you need to hook up SCM change notification to Jenkins.

 

 

GitHub hook trigger for GITScm polling

(GitHub 플러그인 설치시 사용가능)

깃 저장소에 변경사항 (git pull, commit 발생시)시 빌드

 

Poll SCM

지정한 시간에 커밋을 확인해서 변경사항이 있다면 빌드

이 문제 때문에 문서를 찾아 보았다. 1일1빌드를 진행하지만, 아무 커밋도 없으면 굳이 빌드를 진행하지 않기 위함.

ex) 프로젝트 일일 빌드(변경사항이 없으면 빌드하지 않는다)

Configure Jenkins to poll changes in SCM.
Note that this is going to be an expensive operation for CVS, as every polling requires Jenkins to scan the entire workspace and verify it with the server. Consider setting up a "push" trigger to avoid this overhead, as described in this document