@@ -208,6 +208,7 @@ Examples for different programming languages are:
...
@@ -208,6 +208,7 @@ Examples for different programming languages are:
The reason for using a build tool is to be able to build and/or test a code project with one command (after checking out). Another reason is to include dependency management.
The reason for using a build tool is to be able to build and/or test a code project with one command (after checking out). Another reason is to include dependency management.
##### Build tools we are using at the moment
##### Build tools we are using at the moment
***bash scripting**: (BdN Print, Fontane Print)
***bash scripting**: (BdN Print, Fontane Print)
***eXist**: Ant (SADE)
***eXist**: Ant (SADE)
***Java**: Maven (TextGrid)
***Java**: Maven (TextGrid)
...
@@ -222,6 +223,7 @@ The reason for using a build tool is to be able to build and/or test a code proj
...
@@ -222,6 +223,7 @@ The reason for using a build tool is to be able to build and/or test a code proj
***Ruby**: bundler (DARIAH status page)
***Ruby**: bundler (DARIAH status page)
##### Build tools we want to evaluate
##### Build tools we want to evaluate
* gradle
* gradle
### Continuous integration
### Continuous integration
...
@@ -242,6 +244,7 @@ The workflows we are using currently in Jenkins and Gitlab Runner are:
...
@@ -242,6 +244,7 @@ The workflows we are using currently in Jenkins and Gitlab Runner are:
The following example illustrates how the GitLab Runner is used in SADE.
The following example illustrates how the GitLab Runner is used in SADE.
The fully documented version of this file can be viewed [here](https://gitlab.gwdg.de/SADE/SADE/blob/develop/.gitlab-ci.yml).
The fully documented version of this file can be viewed [here](https://gitlab.gwdg.de/SADE/SADE/blob/develop/.gitlab-ci.yml).
- curl -u ci:${EXIST_UPLOAD_PW} -X POST -F file=@${FILENAME} https://ci.de.dariah.eu/exist-upload
- curl -u ci:${EXIST_UPLOAD_PW} -X POST -F file=@${FILENAME} https://ci.de.dariah.eu/exist-upload
```
#### Sample configuration of the Jenkins CI (Multibranch Pipelines)
- On commit and push to the <https://projects.gwdg.de> gitolite repo (such as <https://projects.gwdg.de/projects/tg-crud/repository>) Jenkins on ci.de.dariah.eu <https://ci.de.dariah.eu/jenkins> is notified (see projects' gitolite configuration)
- Jenkins then is doing a checkout and build of configured branches (see Jenkins' project's multibranch pipeline configuration such as <https://ci.de.dariah.eu/jenkins/job/DARIAH-DE-CRUD-Services>. Here comes THE CRUD Jenkinsfile, as it is used for other projects in a very similar way:
```
```
#!/usr/bin/envgroovy
node{
defmvnHome
stage('Preparation'){
mvnHome=tool'Maven 3.5.0'
checkoutscm
}
stage('Build'){
// We are deploying all JARs and WARs build here, SNAPSHOTs and RELEASEs!
sh"cd service && '${mvnHome}/bin/mvn' -U clean verify deploy -Pdhrep.deb"
- Stage *Build*: Build, JAR, WAR, and DEB packages from source code, deploy JAR and WAR packages to the Nexus repo (at the moment <https://ci.de.dariah.eu/nexus> --> in the near future <https://nexus.gwdg.de>). Jenkins is configured to deploy JARs and WARs via Maven and a Nexus deploy-account.
- Stage *Publish*: Publish DEB packages to the DARIAH-DE Aptly Repo <https://ci.de.dariah.eu/aptly>. Jenkins is using a shared library of scripts and publishing is devided into four conditionals: TG version, DH version, SNAPSHOT version, or RELEASE version due to given version suffixes!