-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modifying the Pipelines section #414
Changes from 3 commits
a7f62f0
7630d03
00beb96
05aa06c
dc6124c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,11 @@ | ||
[id="about_pipelines_stage_run"] | ||
= About pipelines and the stage and run environments | ||
|
||
When you create a codebase, a pipeline build is initiated. Pipelines are automated, continuous integration and deployment processes, powered by Jenkins, which define how your application is deployed. | ||
|
||
The free OpenShift Online Starter subscription, included with your {osio} subscription, provides two environments named _Stage_ and _Run_ to deploy your applications. | ||
|
||
Initially, the build pipeline deploys the application to _Stage_, which is accessible to stakeholders for review through a public URL provided by OpenShift Online. If approved and promoted, the pipeline deploys it to the _Run_ environment. This simulates the workflow of pushing an application to a staging environment and reviewing it, before promoting it to production. | ||
|
||
The _Run_ environment is similar to a production environment but is another staging area. The reason _Run_ is not named _Production_ is that the OpenShift Online Starter subscription does not support running production applications. | ||
//See link:https://www.openshift.com/pricing/index.html[purchasing an OpenShift Online Pro subscription] for information about support for running production applications. |
This file was deleted.
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
[id="approving_your_application"] | ||
= Approving your application | ||
|
||
If the quickstart application in the _Stage_ environment runs as expected, approve your application and promote it to the _Run_ environment: | ||
|
||
. Return to the {osio} tab which displays the *Pipeline* view and click btn:[Input Required] at the *Approve* stage of the pipeline. | ||
|
||
. Click btn:[Promote] to promote the build from the _Stage_ environment to the _Run_ environment. The roll out process from _Stage_ to _Run_ requires a few minutes. | ||
+ | ||
image::promote.png[Promote build] | ||
. Optionally, as your build is promoted to _Run_, click *helloworldvertx* or *Build #1* to view the detailed progress of the pipeline or build in your OpenShift Online console, respectively. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This module is called approving your application but it talks about promoting your build more. Perhaps the name should be reassessed based on the content? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. AFAIU, we promote an application to production (in this case run) we do not promote a build. So it's either Promote your application or Approve your application. I picked the latter. But you are right, the word 'build' in a number of places needs to be replaced with application and could have created the perception. Taken care of now. Thanks for noticing. |
||
. When the *Pipeline* view in {osio} indicates that the project is available in the _Run_ environment, click the icon (image:rollout_icon.png[title="Rollout"]) next to *Rollout to Run* to view the application in a new tab. | ||
+ | ||
image::rollout_to_run.png[Rollout to Run] |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -28,7 +28,7 @@ ifeval::["{context}" == "hello-world"] | |
+ | ||
image::choose_mission_runtime.png[Choose mission and runtime] | ||
+ | ||
. In the *Select Pipeline* section, select the first option, then click the blue arrow to continue to the next step. | ||
. In the *Select Pipeline* section, select the first option, then click the blue arrow to continue to the next step. The {osio} pipelines create repeatable, incrementally improving processes that test and deploy the code from creation to execution. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we need this addition in this step? It doesn't seem particularly useful to the step, just sort of marketing-speak-ish? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Removing this for now, agree on the marketing-speak-ish observation, but more so for consistency. OTOH, in the creating application module, we are not explaining the why anywhere. Should this be rethought? Should we not have at least a line to explain the whys in the steps? We ask the user to do 1,2,3...without telling him why he needs to do them, and this is one of the primary areas of focus in OSIO. |
||
+ | ||
image::select_pipeline.png[Select a pipeline] | ||
+ | ||
|
@@ -48,7 +48,7 @@ ifeval::["{context}" == "user-guide"] | |
+ | ||
image::choose_mission_runtime.png[Choose mission and runtime] | ||
+ | ||
. In the *Select Pipeline* section, select the appropriate option, then click the blue arrow to continue to the next step. The first option is suggested for most use cases because it provides stages to test your changes for each pipeline build. For more information see <<working_with_pipelines>>. | ||
. In the *Select Pipeline* section, select the appropriate option, then click the blue arrow to continue to the next step. The {osio} pipelines create repeatable, incrementally improving processes that test and deploy the code from creation to execution. The first option is suggested for most use cases. For more information see <<working_with_pipelines>>. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The exact phrase again. Do we need it here? I suggest removing it in both places because it's just vague and not really telling us anything useful about this step where it's included. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Exact phrase cause it is in the UG ifdef, whereas the previous one was for GS one. Basically I was trying to add a bit of context, but in this case probably not required since we have a link for more information. |
||
+ | ||
image::select_pipeline.png[Select a pipeline] | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,26 @@ | ||
[id="reviewing_your_staged_application"] | ||
= Reviewing your staged application | ||
|
||
When you create a new codebase, the selected pipeline builds your application. It pushes version 1.0.1 of your new application into the _Stage_ environment, and then awaits your approval to deploy into the _Run_ environment. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure I'm reading this correctly, but it sounds like the pipeline is somehow the subject of this part. Does "It" refer to the pipeline? I'm not sure the pipeline itself is doing anything, it's just a pipeline type that the application uses to deploy to stage or run. Can we reword this to reflect this? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So far whatever I have read and understood from my discussions with Devs seems to suggest that the Pipeline triggers/pushes these actions. Our UG docs (not authored by me): https://docs.openshift.io/user-guide.html#selecting_a_pipeline_type, Point #1 (On a totally tangential thought, wonder why this is a numbered list?): "It provides an end to end pipeline that moves your application through all the stages of application development, that is, build your source code, test your changes, rollout to the Stage environment, review, manually approve, and promote the changes to the Run environment." I am not sure I understand your second last sentence, are you suggesting the application is the actor here? But yet, here's an attempt at rewording it: Please note, this was already existing in the docs>Section 5.6 just above the adominition at the end of the module. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see. That sounds really odd to me in non technical terms to have a pipeline be the actor but if it's intentional and accurate, sounds like a non issue. |
||
|
||
<<about_pipelines_stage_run,_Stage_ and _Run_>> are individual OpenShift projects. _Stage_ is a production staging area to review and test changes before they are finalized and then staged on _Run_. | ||
|
||
To review your application on _Stage_: | ||
|
||
. At the top of the page, click *Create*, and then click *Pipelines* to see the build pipelines for your new application. The pipeline first sets your build server, starts the build, and releases the build. When the pipeline build pushes the application to stage, it displays at the *Approve* stage. This could take a few minutes. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The second sentence here again suggests that the pipeline is the actor. I don't think the pipeline itself is doing anything, AFAIK. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How about this? |
||
+ | ||
image::pipeline_firstrun.png[Pipeline First Run] | ||
+ | ||
NOTE: If your pipeline build does not start for more than ten minutes, you can manually start a pipeline build using the instructions at <<pipeline_build_failure>>. | ||
|
||
. Click the icon (image:rollout_icon.png[title="Rollout"]) next to *Rollout to Stage* in the displayed pipeline. OpenShift Online provides this public URL to access the staged quickstart application. | ||
+ | ||
A new browser tab displays the HTTP Booster application running on _Stage_. The Vert.x HTTP booster quickstart produces a simple API behind a REST endpoint over HTTP with a minimalist user interface. | ||
+ | ||
image::vertx_stage.png[Staged Application] | ||
+ | ||
NOTE: If the application does not load, see <<application_not_available>> for troubleshooting information. | ||
|
||
. To test the application, enter a name in the *Name* field and click btn:[Invoke]. The *Result* field displays the JSON result returning from the API. | ||
+ | ||
image::hello-world_john.png[Test the Application] |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,15 @@ | ||
[id="viewing_application_deployment_details"] | ||
= Viewing your application deployment details | ||
|
||
You can see a detailed view of your application pods in the <<about_pipelines_stage_run,stage, and run>> environments, resources consumed in the two environments, and the overall resources used by the application in the *Deployments* view as follows: | ||
|
||
. At the top of the page, click *Create* and then click *Deployments* to see the deployment details. | ||
. In *Applications*, expand *helloworldvertx* to see the application pods and the resources consumed in the *stage* and *run* environments respectively. The *Resource Usage* at the bottom of the screen displays the overall resources used by your applications in {osio}. | ||
+ | ||
image::hello-world_deployments.png[Deployments page] | ||
. To see further deployment details in your OpenShift Online console, in either the *Stage* or *Run* environments, click the options (image:kabob.png[title="Options"]) icon and then click *View OpenShift Console*. | ||
|
||
. If prompted, click btn:[LOGIN WITH RED HAT] to log in to your OpenShift Online account. When logged in, the OpenShift Online console displays an overview of your application. | ||
. In the left pane, click *Applications* > *Deployments* to view details about the application deployment in the appropriate environment. | ||
+ | ||
image::openshift_online_deployments.png[OpenShift Online Deployments] |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
[id="viewing_build_pipeline_logs"] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's very difficult to judge what has changed when we move files, so I wonder if @rkratky's idea about a separate PR for changing file names (if there are any changes within the file) is something to follow in these cases. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure, sounds like a good convention to follow from henceforth, meanwhile here is an attempt at trying to lessen the pain a bit: Existing modules mapped to renamed ones: Earlier sequence of modules: Current Sequence of modules: |
||
= (Optional) Viewing the build pipeline logs | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This has changed to optional but it's not meant to be. While the user waits, we definitely want them to go see the logs to get an idea of what's happening (and see how to access this information in their OSO account) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Viewing the build pipeline logs is an optional section even in the original doc. I distinctly remember back in the demo days this was used to divert attention from the long wait time for a pipeline to go from one stage to another. I have tested this around 3 or 4 times now and the pipelines are executed fairly faster now. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. IMO, it's useful to know where the logs are but if it's not a necessary part of the workflow anymore, we can just get rid of it, tbh. No need to clutter it up with more instructions that are useful. |
||
|
||
Optionally, while you wait for the pipeline build, you can view the build details in the Jenkins log. For experienced users, these logs are useful when troubleshooting problems with builds if required. | ||
|
||
. In the *Pipeline* page, click *View Log* for the build pipeline in progress. | ||
. When prompted, log into Jenkins with your OpenShift Online account. If the page does not display, you may need to wait for a few minutes for the Jenkins instance to initialize and try again. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Probably my own fault, but there shouldn't be a "may" in our docs. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep, may, could, were part of existing docs, but weeded them out now, thanks for pointing them out. |
||
Once you are logged in, the page displays the logs for your pipeline build. | ||
+ | ||
image::pipeline_jenkins.png[Pipeline Build Logs in Jenkins] | ||
+ | ||
WARNING: Do not click the *Proceed* or *Abort* options at the end of the logs. | ||
|
||
You can now examine the log output to troubleshoot build problems if needed. |
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,11 @@ | ||
[id="viewing_codebase_github"] | ||
= Viewing your codebase in GitHub | ||
|
||
After reviewing your pipeline build running in {osio} and OpenShift Online, view your application <<about_application_codebases,codebase>> in GitHub as follows: | ||
|
||
. Return to the *Pipeline* view in {osio}, the *Source Repository* provides the link to the codebase of your application. Right click the link and open it in a new tab to see your codebase in GitHub. | ||
. In the repository, click the *Jenkinsfile* to view details on staging and rolling out of the pipelines. | ||
+ | ||
image::proj_gh.png[Project Code in GitHub] | ||
|
||
Use the codebase link to review code commits and details in your GitHub repository. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,14 +1,14 @@ | ||
[id="viewing_projects_oso"] | ||
= Viewing projects in OpenShift Online | ||
[id="viewing_oso_projects"] | ||
= Viewing your OpenShift Online projects | ||
|
||
To view the OpenShift Online projects that support the pipeline for your project, navigate to your link:https://console.starter-us-east-2.openshift.com/console/projects/[OpenShift Online Console]. | ||
To view all the OpenShift Online projects that support your application, navigate to link:https://console.starter-us-east-2.openshift.com/console/projects/[*My Projects*] in the OpenShift Online Console. | ||
|
||
image::oso_projects.png[OpenShift Online Projects] | ||
|
||
This page displays the following projects and namespaces that are created in OpenShift Online: | ||
|
||
* The *_username_* project is where your pipelines run. Your OpenShift Online user name is the name of your project. | ||
* The *_username-che_* project represents your <<about_workspaces,Che Host and workspaces>>. | ||
* The *_username-jenkins_* project represents your Jenkins Master or your Jenkins Slaves. Click *Monitoring* after clicking this project to access your Jenkins console. | ||
* The *_username-jenkins_* project represents your Jenkins Master for your Jenkins Slaves. Click this project, and then click *Monitoring* in the left pane to access your Jenkins console. | ||
* The *_username-run_* project is identical to the *_username-stage_* project and is an environment for experimenting with your OpenShift pods and monitoring the memory usage for your application. | ||
* The *_username-stage_* project is for your personal use. Use this project to see the pods that are created when pipelines are triggered in {osio}. For maintenance, select this project and power down individual pods as required. |
This file was deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd avoid using "roll out process". First, the language seems a bit informal to use, but also the UI still calls it "rollout" rather than roll out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed.