This post was originally posted by Jenkins Chinese Community
Changes over the past five years, such as moving to the public cloud and from virtual machines to containers, have revolutionized what it means to build and deploy software.
Take Kubernetes for example. Open-source by Google in 2014, it is now supported by all major public cloud providers — giving developers a great way to package applications into Docker containers and deploy them to any Kubernetes cluster.
High performance development using CI/CD, Kubernetes, and Jenkins X
Technically, high-performance teams are almost always necessary for success, and continuous integration, continuous deployment (CI/CD), small iterations, and rapid feedback are the building blocks. Setting up CI/CD for your cloud-native application can be difficult. By automating everything, developers can spend valuable time delivering the actual business.
How to be an effective team using containers, continuous delivery, and Kubernetes? That’s where Jenkins X comes in.
“The Jenkins X concept is to provide all developers with their own Navy nautical butler that can help you navigate the ocean of continuous delivery.” – James Strachan
Jenkins X helps you automate your CI/CD in Kubernetes – you don’t even need to learn Docker or Kubernetes!
What can Jenkins X do?
Jenkins X automatically installs, configures and upgrades Jenkins and other applications (Helm, Skaffold, Nexus, etc.) on Kubernetes. It uses Docker images, Helm diagrams, and pipelining to automate CI/CD for applications. It uses GitOps to manage upgrades between environments and provides a lot of feedback by commenting on pull requests and production time.
Introduction to Jenkins X
To install Jenkins X, you first need to install jX binaries on your machine or cloud provider. There are $300 credits available from Google Cloud, so I decided to start there.
Install Jenkins X on Google Cloud and create clusters
Browse to cloud.google.com and log in. If you don’t already have an account, sign up for a free trial. Go to the console (there is a link in the upper right corner) and activate Google Cloud Shell. Copy and paste the following commands into the shell.
The curl -l https://github.com/jenkins-x/jx/releases/download/v1.3.79/jx-linux-amd64.tar.gz | tar XZV sudo jx/usr/mvlocal/bin
Copy the code
Note: Google Cloud Shell will terminate any changes made outside of your home directory after an hour, so you may have to rerun these commands. The good news is that they will be in your history, so you just need to arrow up and enter. You can also delete the sudo mv command above and add the following to.bashrc.
export PATH=$PATH:.
Copy the code
Use the following command to create a cluster on GKE (Google Kubernetes Engine). You may have to enable GKE for your account.
jx create cluster gke --skip-login
Copy the code
If you are prompted to download Helm, be sure to install it. You will be prompted to select the Google Cloud Zone. I suggest choosing a seat near you. I chose US-West 1-A because I live near Denver, Colorado. For the Google Cloud Machine type, I chose N1-standard-2 and used the default values of min (3) and Max (5) nodes.
For the GitHub name, type your own (e.g. Mraible) and the email you have registered on GitHub (e.g. [email protected]). I tried to use OktaDeveloper (a GitHub organization) but I couldn’t get it to work.
Note: GitHub integration will fail if two-step authentication is enabled for your account. If you want to complete this process successfully, you’ll need to disable it on GitHub.
When prompted to install ingress Controller, press Enter to confirm. Press Enter again to select the default domain.
You will be prompted to create a GitHub API Token. Click on the URL provided and name it “Jenkins X”. Copy and paste the token value back to the console.
Have a cup of coffee, drink or do some push-ups after the installation is complete. It may take a few minutes.
The next step is to copy the API token from Jenkins to your console. Follow the instructions provided in the console.
When done, run the JX Console and click the link to log in to the Jenkins instance. Click Administration and upgrade Jenkins and all of its plug-ins (Plug-in Manager > scroll to the bottom and select All). If you fail to perform this step, you will not be able to move from GitHub pull Request to Jenkins X CI process.
Create a Spring Boot application
When I first started using Jenkins X, I tried importing existing projects. Even though my application uses Spring Boot, there is no pom.xml in the root directory, so Jenkins X considers it a Node.js application. For this reason, I recommend first creating a blank Spring Boot application to ensure Jenkins X is created correctly.
Create a simple Spring Boot application from Cloud Shell:
jx create spring -d web -d actuator
Copy the code
This command uses Spring Initializr, so you will be prompted to make some choices. Here are my choices:
QUESTION | ANSWER |
---|---|
Language | java |
Group | com.okta.developer |
Artifact | okta-spring-jx-example |
Tip: Choosing a succinct name for your artifact name will ease your pain. Jenkins X has a limit of 53 characters for version names, oktadeveloper/ okta-spring-boot-Jenkinsx-example will make it more than two characters.
Choose the default values for the Git username, initialize Git, and commit messages. If you don’t want to use an individual account, you can choose the organization you want to use. Run the following command to see the CI/CD pipeline for your application.
jx get activity -f okta-spring-jx-example -w
Copy the code
Run jX Console, click the generated link, and navigate to your project (if you want a more visually rich view).
! [Image title]
This process performs a number of tasks:
- Create a version for your project.
- Create a pull Request for the demo environment project.
- Deploy it automatically to the demo environment so you can see it in action.
Merge status checks all passed so the promotion worked! The Application is available at: http://okta-spring-jx-example.jx-staging.35.230.106.169.nip.ioCopy the code
Note: Since Spring Boot does not provide a welcome page by default, opening the above URL returns 404.
Deploy the Spring Boot application into production using Jenkins X
By default, Jenkins X will only be automatically deployed to the demo environment. You can manually improve from demo to production use:
Jx promote okta-spring-jx-example --version 0.0.1 --env productionCopy the code
You can use the JX Edit Environment to change the production environment to use automatic deployment.
Now that you know how to use Jenkins X and a simple Spring Boot application, let’s look at how to make it work with a more practical example.
Secure your Spring Boot application and add Angular PWA
Over the past few months, I’ve written a series of posts about building PWA (progressive Web applications) using Ionic/Angular and Spring Boot.
- Use Okta to protect your cryptocurrency wealth by tracking PWA
- Use Okta to securely store users’ data instead of local storage
- Test the Spring Boot API and The Hitchhiker guide for Angular components using WireMock, Jest, Protractor, and Travis CI
- Deploying your Spring Boot + Angular PWA as an Artifact This is the final blog post in the series. I believe this is a good example of a real application, as it has many unit and integration tests, including end-to-end testing with the Protractor. Let’s see how to automate the production path using Jenkins X and Kubernetes!
Clone the Spring Boot project just created from GitHub (make sure to change {yourUsername} in the URL) :
git clone https://github.com/{yourUsername}/okta-spring-jx-example.git okta-jenkinsx
Copy the code
Clone the created project with Spring Boot + Angular as an artifact in a neighboring directory:
git clone https://github.com/oktadeveloper/okta-spring-boot-angular-auth-code-flow-example.git spring-boot-angular
Copy the code
In terminal, navigate to Okta-JenkinsX and delete files that are no longer needed:
cd okta-jenkinsx
rm -rf .mvn src mvnw* pom.xml
Copy the code
The result should be a directory structure containing the following files:
$tree.. ├ ─ ─ charts │ ├ ─ ─ okta - spring - jx - example │ │ ├ ─ ─ Chart. The yaml │ │ ├ ─ ─ a Makefile │ │ ├ ─ ─ the README. Md │ │ ├ ─ ─ Templates │ │ │ ├ ─ ─ deployment. Yaml │ │ │ ├ ─ ─ _helpers. TPL │ │ │ ├ ─ ─ the TXT │ │ │ └ ─ ─ service. The yaml │ │ └ ─ ─ ├── lessons.├ ─ lessons.├ ─ lessons.├ ─ lessons.├ ─ lessons.├ ─ lessons.├ ─ lessons.├ ─ lessons.├ ─ lessons.├ ─ lessons.├ ─ lessons.├ ─ lessons.├ ─ lessons.├ ─ lessons.├ ─ lessons.├ ─ Lessons.├ ─ Lessons.├ ─ Lessons.├ ─ Lessons.├ ─ Lessons.├ ─ Lessons.├ ── Genkinsfile ├ ─ Skaffold. yaml 4 directories, 15 filesCopy the code
Copy all spring-boot-Angular files to Okta-Jenkinsx.
cp -r .. /spring-boot-angular/* .Copy the code
When testing the application using Travis CI, I ran NPM Install as part of the process. With Jenkins X, it’s easier to keep everything in one container (such as Maven or Nodejs), So add execution in frontend-maven-plugin (in hold-api /pom.xml) to run NPM install (tip: you will need execution id== ‘NPM install’ to add to existing pom.xml).
Now is a good time for Okta-JenkinsX to open a directory as a project in an IDE like IntelliJ IDEA, Eclipse, Netbeans, or VS Code!
<plugin>
<groupId>com.github.eirslett</groupId>
<artifactId>frontend-maven-plugin</artifactId>
<version>${frontend-maven-plugin.version}</version> <configuration> <workingDirectory>.. /crypto-pwa</workingDirectory> </configuration> <executions> <execution> <id>install node and npm</id> <goals> <goal>install-node-and-npm</goal> </goals> <configuration> <nodeVersion>${node.version}</nodeVersion>
</configuration>
</execution>
<execution>
<id>npm install</id>
<goals>
<goal>npm</goal>
</goals>
<phase>generate-resources</phase>
<configuration>
<arguments>install --unsafe-perm</arguments>
</configuration>
</execution>
...
</executions>
</plugin>
Copy the code
Note: the –unsafe-perm flag is necessary because Jenkins X is running the build as root. I found this solution in the Node-Sass troubleshooting instructions.
Add actuators and disable HTTPS
The Jenkins X relies on Spring Boot’s Actuator to perform health checks. This means that if you don’t include it in your project (or have /actuator/ Health guards), Jenkins X will report that your app fails to start.
Add the Actuator Starter as a dependency to hold-API/POM.xml:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
Copy the code
You also need to allow access to it to run health checks. Jenkins X will deploy your application in an NGINX server, so you will also need to force HTTPS off, otherwise you will not be able to access your application. Modify the holdings – API/SRC/main/Java /… / SecurityConfiguration. Java to allow holdings – API/SRC/main/Java /… / SecurityConfiguration. Java and delete requiresSecure ().
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {
@Override
public void configure(WebSecurity web) throws Exception {
web.ignoring().antMatchers("/**/*.{js,html,css}");
}
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.csrf().csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
.and()
.authorizeRequests()
.antMatchers("/"."/home"."/api/user"."/actuator/health").permitAll() .anyRequest().authenticated(); }}Copy the code
Adjust the paths in Dockerfile and Jenkinsfile
Since this project is built in a subdirectory rather than a root directory, update./Dockerfile to find the Holds-API file.
FROM openjdk:8-jdk-slim
ENV PORT 8080
ENV CLASSPATH /opt/lib
EXPOSE 8080
# copy pom.xml and wildcards to avoid this command failing if there's no target/lib directory
COPY holdings-api/pom.xml holdings-api/target/lib* /opt/lib/
# NOTE we assume there's only 1 jar in the target dir
# but at least this means we don't have to guess the name
# we could do with a better way to know the name - or to always create an app.jar or something
COPY holdings-api/target/*.jar /opt/app.jar
WORKDIR /opt
CMD ["java"."-jar"."app.jar"]
Copy the code
You also need to update Jenkinsfile so that it can run any MVN commands in the hold-API directory. Also add the -pprod configuration file. Such as:
// in the 'CI Build and push snapshot' stage
steps {
container('maven') {
dir ('./holdings-api') {
sh "mvn versions:set -DnewVersion=$PREVIEW_VERSION"
sh "mvn install -Pprod"}}... } / /in the 'Build Release' stage
dir ('./holdings-api') {
sh "mvn versions:set -DnewVersion=\$(cat .. /VERSION)"}... dir ('./holdings-api') {
sh "mvn clean deploy -Pprod"
}
Copy the code
This should be enough to make this application usable with Jenkins X. However, unless you have an Okta account and configure it accordingly, you won’t be able to log in to it.
Why use Okta?
In short, we’ve made identity management simpler, more secure, and more scalable than you might be used to. Okta is a cloud service that allows developers to create, edit, and securely store user accounts and user account data and connect them to one or more applications. Our API enables you to:
- Authenticate and authorize users
- Store data about users
- Perform password-based and social logins
- Secure applications with multiple authentications
- Learn more! Are you tempted to look at our product documentation? Sign up for a always free developer account and when you’re done, please come back so we can learn more about CI/CD through Spring Boot and Jenkins X!
Create a Web application for the Spring Boot application in Okta
After completing the setup process, log in to your account and navigate to Applications > Add Application. Click Web and Next. On the next page, enter the following values and click Done (you must click Done and then edit to modify the logout redirection URI).
- Application Name:
Jenkins X
- The default URI:
http://localhost:8080
- Login redirection URI:
http://localhost:8080/login
- Unregister the redirection URI:
http://localhost:8080
Open theholdings-api/src/main/resources/application.yml
And paste the values from your org/app into it.
okta:
client:
orgUrl: https://okta.okta.com
token: XXX
security:
oauth2:
client:
access-token-uri: https://okta.okta.com/oauth2/default/v1/token
user-authorization-uri: https://okta.okta.com/oauth2/default/v1/authorize
client-id: {clientId}
client-secret: {clientSecret}
resource:
user-info-uri: https://okta.okta.com/oauth2/default/v1/userinfo
Copy the code
You will notice that the token value is XXX. This is because I prefer to read it from an environment variable rather than check in source control. You might want to do this for your customer key as well, but I’m just making a property for brevity. To create an API token:
- Navigate to API > Tokens and click Create Token
- Name the token (for example, “Jenkins X”) and set its value to
OKTA_CLIENT_TOKEN
Environment variables. You need to add one to your organization’s user profileholdings
Property to store your cryptocurrency in Okta. Navigate to theUsers > Profile Editor. Click on theProfileThe first configuration file in the table. You can identify it by its Okta logo. Click on theAdd AttributeAnd use the following values:
- Display name:
Holdings
- The variable name:
holdings
- Description:
Cryptocurrency Holdings
After performing these steps, you should be able to navigate tohttp://localhost:8080
And log in by running the following command:
cd holdings-api
./mvnw -Pprod package
java -jar target/*.jar
Copy the code
Storing Secrets in Jenkins X is very simple and storing environment variables locally. But how do you do that in Jenkins X? Just look at its credentials function. Here’s how to use it:
- Run on Google Cloud Shell
jx console
To get Jenkins X url - Click the link, log in, and then click Administration at the top
- Click Credentials > (Global) > Add Credentials (on the left)
- Select Secret Text from the drop-down list and enter OKTA_CLIENT_TOKEN for ID
- Copy/paste the Okta API token intoSecretField when you’re inside, add secrets:
OKTA_APP_ID
,E2E_USERNAME
和E2E_PASSWORD
. The first one you createdJenkins X
OIDC application ID. You can get its value by navigating to your application on Okta and copying the value from the URL. theE2E-*
The key should be the credential to run the Protractor test. You may want to create a new user for this purpose.
You can access these values in Jenkinsfile by adding them to the section near the top of the environment.
environment {
ORG = 'mraible'
APP_NAME = 'okta-spring-jx-example'
CHARTMUSEUM_CREDS = credentials('jenkins-x-chartmuseum')
OKTA_CLIENT_TOKEN = credentials('OKTA_CLIENT_TOKEN')
OKTA_APP_ID = credentials('OKTA_APP_ID')
E2E_USERNAME = credentials('E2E_USERNAME')
E2E_PASSWORD = credentials('E2E_PASSWORD')}Copy the code
Pass the environment variables to the Docker container
To transfer the OKTA_CLIENT_TOKEN environment variable to the Docker container, see:
sh "make preview"
Copy the code
And change it to:
sh "make OKTA_CLIENT_TOKEN=\$OKTA_CLIENT_TOKEN preview"
Copy the code
At this point, you can create branches, commit changes, and verify that everything in Jenkins X works.
cd. git checkout -b add-secure-app git add . git commit -m"Add Bootiful PWA"
git push origin add-secure-app
Copy the code
Open your browser and navigate to the repository on GitHub and create the pull Request. It should look like this after creation.
If your pull Request test passes, you should see some green markers and Jenkins X comments indicating that your application is available in the preview environment.
If you click on the link here and try to log in, you may get an error from Okta stating that the redirected URI is not yet whitelisted.
Add the weighted URI automatically in Okta
When you create applications in Okta and run them locally, it’s easy to know what the application’s redirection URI will be. For this particular application, they will be used to login to http://localhost:8080/login, http://localhost:8080 for cancellation. When you go into production, urls are usually well known as well. However, with Jenkins X, urls are dynamic and created dynamically based on your pull request number.
To do this using Okta, you create a Java class that interacts with the Okta API. Create holdings – API/SRC/test/Java /… / cli/AppRedirectUriManager. Java and use the following code to perfect it.
package com.okta.developer.cli;
import com.okta.sdk.client.Client;
import com.okta.sdk.lang.Collections;
import com.okta.sdk.resource.application.OpenIdConnectApplication;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.boot.ApplicationArguments;
import org.springframework.boot.ApplicationRunner;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import java.util.LinkedHashSet;
import java.util.List;
import java.util.Set;
@SpringBootApplication
public class AppRedirectUriManager implements ApplicationRunner {
private static final Logger log = LoggerFactory.getLogger(AppRedirectUriManager.class);
private final Client client;
@Value("${appId}")
private String appId;
@Value("${redirectUri}")
private String redirectUri;
@Value("${operation:add}")
private String operation;
public AppRedirectUriManager(Client client) {
this.client = client;
}
public static void main(String[] args) {
SpringApplication.run(AppRedirectUriManager.class, args);
}
@Override
public void run(ApplicationArguments args) {
log.info("Adjusting Okta settings: {appId: {}, redirectUri: {}, operation: {}}", appId, redirectUri, operation);
OpenIdConnectApplication app = (OpenIdConnectApplication) client.getApplication(appId);
String loginRedirectUri = redirectUri + "/login";
// update redirect URIs
List<String> redirectUris = app.getSettings().getOAuthClient().getRedirectUris();
// use a set so values are unique
Set<String> updatedRedirectUris = new LinkedHashSet<>(redirectUris);
if (operation.equalsIgnoreCase("add")) {
updatedRedirectUris.add(loginRedirectUri);
} else if (operation.equalsIgnoreCase("remove")) {
updatedRedirectUris.remove(loginRedirectUri);
}
// todo: update logout redirect URIs with redirectUri (not currently available in Java SDK)
app.getSettings().getOAuthClient().setRedirectUris(Collections.toList(updatedRedirectUris));
app.update();
System.exit(0); }}Copy the code
This class uses Spring Boot’s CLI (command line interface) support, which makes it possible to invoke it using the Exec Maven plug-in. To add support for running Maven, make the following changes in hold-API /pom.xml.
<properties>
...
<exec-- maven plugin. Version > 1.6.0 < /exec-maven-plugin.version> <appId>default</appId> <redirectUri>override-me</redirectUri> </properties> <! -- dependencies --> <build> <defaultGoal>spring-boot:run</defaultGoal> <finalName>holdings-app-${project.version}</finalName> <plugins> <! -- existing plugins --> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec-maven-plugin</artifactId>
<version>${exec-maven-plugin.version}</version>
<executions>
<execution>
<id>add-redirect</id>
<goals>
<goal>java</goal>
</goals>
</execution>
</executions>
<configuration>
<mainClass>com.okta.developer.cli.AppRedirectUriManager</mainClass>
<classpathScope>test</classpathScope>
<arguments>
<argument>appId ${appId} redirectUri ${redirectUri}</argument>
</arguments>
</configuration>
</plugin>
</plugins>
</build>
Copy the code
Jenkinsfile is then updated to add a section of MVN Exec: Java to run after the image is built.
dir ('./charts/preview') {
container('maven') {
sh "make preview"
sh "make OKTA_CLIENT_TOKEN=\$OKTA_CLIENT_TOKEN preview"
sh "jx preview --app $APP_NAME--dir .. /.."
}
}
// Add redirect URI in Okta
dir ('./holdings-api') {
container('maven') {
sh ' '' yum install -y jq previewURL=$(jx get preview -o json|jq -r ".items[].spec | select (.previewGitInfo.name==\\"$CHANGE_ID\\") | .previewGitInfo.applicationURL") mvn exec:java@add-redirect -DappId=$OKTA_APP_ID -DredirectUri=$previewURL '' '}}Copy the code
To submit and push your changes, the application should be updated with the redirection URI at http://{yourPreviewURL}/login. You will need to manually add a logout redirection URI for http://{yourPreviewURL}, as Okta’s Java SDK does not currently support this feature.
To upload your pull request to the demo, merge it and push the main branch to the demo. Unfortunately, you will not be able to log in. This is because no process registers the staging site’s redirect URI using your Okta application. If you add urIs manually, everything should work.
Run the Protractor test in Jenkins X
Figuring out how to run end-to-end testing in Jenkins X was the hardest part for me. I first added a new Maven configuration file that allowed me to run tests using Maven instead of NPM.
Note: to make this configuration file, you will need to login http://localhost:8000/login redirect URI added to your application, and will redirect URI http://localhost:8000 as revoked.
<profile> <id>e2e</id> <properties> <! -- Hard-code port instead of using build-helper-maven-plugin. --> <! -- This way, you don't need to add a redirectUri to Okta app. -->
8000
org.springframework.boot
spring-boot-maven-plugin
pre-integration-test
start
--server.port=${http.port}
post-integration-test
stop
com.github.eirslett
frontend-maven-plugin
${frontend-maven-plugin.version}
.. /crypto-pwa
webdriver update
npm
pre-integration-test
run e2e-update
ionic e2e
npm
integration-test
${http.port}
true
run e2e-test
Copy the code
Tip: You may notice that I had to split two different executions for E2E-update and E2E-test. I found running NPM e2e incompatible with frontend-maven-plugin because it only calls other NPM run commands. It seems that you need to call the binaries directly when using frontend-maven-plugin.
Instead of the TRAVIS environment variable, the CI variable is used. This change need to update the crypto – pwa/test/protractor. Conf. Js to match.
baseUrl: (process.env.CI) ? 'http://localhost:' + process.env.PORT : 'http://localhost:8100'.Copy the code
To make these changes, you should be able to run./ MVNW verify-pprod,e2e to run end-to-end tests locally. Note that you need to define E2E_USERNAME and E2E_PASSWORD as environment variables.
When I first tried this feature in Jenkins X, I found that the Jenkins-Maven agent did not have Chrome installed. I found it difficult to install and found that Jenkins-Nodejs was pre-installed with Chrome and Xvfb. When I first tried it, I encountered the following errors:
[21:51:08] E/launcher - unknown error: DevToolsActivePort file doesn't exist
Copy the code
This error is caused by a Chrome on Linux problem. I found the solution was to specify -disable-dev-shm-usage in chromeOptions for Protractor. I’ve also added some additional flags that I recommend. I particularly like — Headless, which runs locally, so the browser doesn’t pop up and get in my way. If I want to see the process in real time, I can quickly remove this option.
If you want to see on Jenkins X Protractor test run of the project, the need to modify the crypto – pwa/test/Protractor. Conf. ChromeOptions js to specify the following content:
capabilities: {
'browserName': 'chrome'.'chromeOptions': {
'args': ['--headless'.' '--disable-gpu', '--no-sandbox', '--disable-extensions', '--disable-dev-shm-usage']}},Copy the code
Then add a new Run E2E Tests phase to Jenkinsfile between the CI Build and Build Release phases. If it helps, you can see the final Jenkins document.
stage('Run e2e tests') {
agent {
label "jenkins-nodejs"
}
steps {
container('nodejs') {
sh ' '' yum install -y jq previewURL=$(jx get preview -o json|jq -r ".items[].spec | select (.previewGitInfo.name==\\"$CHANGE_ID\\") | .previewGitInfo.applicationURL") cd crypto-pwa && npm install --unsafe-perm && npm run e2e-update Xvfb :99 & sleep 60s DISPLAY=:99 npm run e2e-test -- --baseUrl=$previewURL '' '}}}Copy the code
Once you’ve made all these changes, create a new branch, check in your changes, and create a pull request on GitHub.
git checkout -b enable-e2e-tests
git add .
git commit -m "Add stage for end-to-end tests"
git push origin enable-e2e-tests
Copy the code
I did need to make a few extra tweaks to pass all the Protractor tests:
- in
crypto-pwa/e2e/spec/login.e2e-spec.ts
Medium, I can’t passshould show a login button
Test, so I ignored it and put it(…) Instead of xit (…). . - In the same file, I changed the 2000 ms timeout to 5000 ms and the 5000 ms timeout to 30000 ms.
- in
crypto-pwa/test/protractor.conf.js
In, I changed defaultTimeoutInterval to 600000. The first run time test may fail because the logout redirection URI is not configured for the new preview environment. Update the Okta application’s logout redirection URI to match your PR’s preview environment URI, re-pull the request test, and everything should pass!
You can find the source code for the completed application in this example on GitHub.
Learn more about Jenkins X, Kubernetes and Spring Boot
To learn more about Spring Boot, Jenkins X, and Kubernetes, check out the following resources:
- Deploy Your Secure Spring Boot + Angular PWA as a Single Artifact
- Build a Basic CRUD App with Angular 5.0 and Spring Boot 2.0
- Introducing Jenkins X: a CI/CD solution for modern cloud applications on Kubernetes
- If you’re running production applications on Kubernetes, I suggest you look into Jenkins X. It provides a way to do CI/CD in the same environment, iterate quickly and deliver business value faster for your customers.
Jenkins X also includes a DevPods feature that can be automatically deployed and saved while developing on a laptop. I’m not sure DevPods is suitable for JavaScript applications that require production transformation steps. I’d rather have WebPack and Browsersync refresh my local browser in seconds than wait a few minutes to create and deploy a Docker image to Kubernetes.
For a great overview and demonstration of Jenkins X, watch James Strachan’s Jenkins X: Continuous Delivery for Kubernetes at the Virtual JUG Conference in June 2018.
If you have any questions, please add a comment below, post on Twitter, or ask a question in our developer forum. For notifications of future blog posts and developer wisdom, you can follow my entire team on Twitter.
Adding CI/CD to Spring Boot applications using Jenkins X and Kubernetes was originally posted to the Okta Developer blog on July 11, 2018.
Translator: Shi Yanjun