diff --git a/spring-cloud-pipelines/1.0.0.M7/multi/multi__introduction.html b/spring-cloud-pipelines/1.0.0.M7/multi/multi__introduction.html index 9a0bf898..7c48a0d0 100644 --- a/spring-cloud-pipelines/1.0.0.M7/multi/multi__introduction.html +++ b/spring-cloud-pipelines/1.0.0.M7/multi/multi__introduction.html @@ -10,9 +10,11 @@ step and describe it in details.
In the concourse folder you can find all the necessary scripts and setup to run Concourse demo.
In the docs section you have the whole documentation of the project.
In the jenkins folder you can find all the necessary scripts and setup to run Jenkins demo.
This repository can be treated as a template for your pipeline. We provide some opinionated implementation that you can alter to suit your needs. The best approach to use it to build your production projects would be to download the Spring Cloud Pipelines repository as ZIP, then -init a Git project there and modify it as you wish.
$ curl -LOk https://github.com/spring-cloud/spring-cloud-pipelines/archive/v1.0.0.M6.zip -$ unzip v1.0.0.M6.zip -$ cd spring-cloud-pipelines-v1.0.0.M6 +init a Git project there and modify it as you wish.$ # pass the branch (e.g. master) or a particular tag (e.g. v1.0.0.RELEASE) +$ SC_PIPELINES_RELEASE=... +$ curl -LOk https://github.com/spring-cloud/spring-cloud-pipelines/archive/${SC_PIPELINES_RELEASE}.zip +$ unzip ${SC_PIPELINES_RELEASE}.zip +$ cd spring-cloud-pipelines-${SC_PIPELINES_RELEASE} $ git init $ # modify the pipelines to suit your needs $ git add . diff --git a/spring-cloud-pipelines/1.0.0.M7/multi/multi__jenkins_faq.html b/spring-cloud-pipelines/1.0.0.M7/multi/multi__jenkins_faq.html index 051f02d9..c951ef98 100644 --- a/spring-cloud-pipelines/1.0.0.M7/multi/multi__jenkins_faq.html +++ b/spring-cloud-pipelines/1.0.0.M7/multi/multi__jenkins_faq.html @@ -22,14 +22,14 @@ scripts without changing the whole pipeline.
git tag -l | xargs -n 1 git push --delete originjdk8 configuredJDK_VERSION env var and point to the proper one![]() | Tip |
|---|---|
The docker image comes in with Java installed at |
To change the default one just follow these steps:
-
-
-
-
+
+
+
+
And that’s it!
With scripted that but if you needed to this manually then this is how to do it:
-
-
-
No problem, just set the property / env var to true
AUTO_DEPLOY_TO_STAGE to automatically deploy to stageAUTO_DEPLOY_TO_PROD to automatically deploy to prodNo problem, just set the API_COMPATIBILITY_STEP_REQUIRED env variable
+
+
+
No problem, just set the property / env var to true
AUTO_DEPLOY_TO_STAGE to automatically deploy to stageAUTO_DEPLOY_TO_PROD to automatically deploy to prodNo problem, just set the API_COMPATIBILITY_STEP_REQUIRED env variable
to false and rerun the seed (you can pick it from the seed
job’s properties too).
When you get sth like this:
19:01:44 stderr: remote: Invalid username or password. 19:01:44 fatal: Authentication failed for 'https://github.com/marcingrzejszczak/github-webhook/' diff --git a/spring-cloud-pipelines/1.0.0.M7/multi/multi__jenkins_pipeline_common.html b/spring-cloud-pipelines/1.0.0.M7/multi/multi__jenkins_pipeline_common.html index f003a9bf..0b02713b 100644 --- a/spring-cloud-pipelines/1.0.0.M7/multi/multi__jenkins_pipeline_common.html +++ b/spring-cloud-pipelines/1.0.0.M7/multi/multi__jenkins_pipeline_common.html @@ -59,15 +59,15 @@ of Java installation and the others to another one.
Configure of the build step and modify the Git name / email.
If you want to set it globally you’ll have to remove the section from the build
step and follow these steps to set it globally.You can set Git email / user globally like this:
-
-
-
+
+
+
The scripts will need to access the credential in order to tag the repo.
You have to set credentials with id: git.
Below you can find instructions on how to set a credential (e.g. for Cloud Foundry cf-test credential but
remember to provide the one with id git).
-
-
-
-
Figure 7.7. Fill out the user / password and provide the git credential ID (in this example cf-test)

+
+
+
+
Figure 7.7. Fill out the user / password and provide the git credential ID (in this example cf-test)

./gradlew clean build
![]() | Warning |
|---|---|
The ran test only checks if your scripts compile. |
Check out the tutorial. Provide the link to this repository in your Jenkins installation.
![]() | Warning |
|---|---|
Remember that views can be overridden that’s why the suggestion is to contain in one script all the logic needed to build a view
for a single project (check out that |
If you would like to run the pre-configured Jenkins image somewhere other than your local machine, we diff --git a/spring-cloud-pipelines/1.0.0.M7/multi/multi__opinionated_implementation.html b/spring-cloud-pipelines/1.0.0.M7/multi/multi__opinionated_implementation.html index 7d754a5c..2a3e1a5f 100644 --- a/spring-cloud-pipelines/1.0.0.M7/multi/multi__opinionated_implementation.html +++ b/spring-cloud-pipelines/1.0.0.M7/multi/multi__opinionated_implementation.html @@ -1,16 +1,16 @@
For the demo purposes we’re providing Docker Compose setup with Artifactory and Concourse / Jenkins tools. -Regardless of the picked CD application for the pipeline to pass one needs either
Eureka for Service DiscoveryStub Runner Boot for running Spring Cloud Contract stubs.![]() | Tip | ||
|---|---|---|---|
In the demos we’re showing you how to first build the
In this step we’re generating a version of the pipeline, next we’re - running unit, integration and contract tests. Finally we’re:
During this phase we’re executing a |
In this step we’re generating a version of the pipeline, next we’re + running unit, integration and contract tests. Finally we’re:
During this phase we’re executing a Maven build using Maven Wrapper or a Gradle build using Gradle Wrapper
, with unit and integration tests. We’re also tagging the repository with dev/${version} format. That way in each
subsequent step of the pipeline we’re able to retrieve the tagged version. Also we know
exactly which version of the pipeline corresponds to which Git hash.
Once the artifact got built we’re running API compatibility check.
Here we’re
Eureka infrastructure application to PaaSHere we’re
Eureka infrastructure application to PaaS![]() | Tip | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Currently due to port constraints in Cloud Foundry
we cannot run multiple stubbed HTTP services in the cloud so to fix this issue we’re running
the application with smoke tests against the freshly deployed application surrounded by stubs.
If those tests pass then we have a high probability that the application is backwards compatibleHere we’re
Here we’re
Next we have a manual step in which:
The step is manual by default due to the fact that stage environment is often shared between teams and some preparations on databases / infrastructure have to take place before running the tests. -Ideally these step should be fully automatic. The step to deploy to production is manual but ideally it should be automatic.
|