codepipeline 0.3.0 → 0.3.1

data/docs/_docs/dsl/pipeline/action.md

@@ -1,28 +0,0 @@
----
-title: Action General Method
-nav_text: Action
-categories: dsl-pipeline
-nav_order: 11
----
-
-The `action` method is a general way to add Actions to pipeline Stages. Generally, it is recommended to use the helper methods like [codebuild]({% link _docs/dsl/pipeline/codebuild.md %}) and [approve]({% link _docs/dsl/approve.md %}) when possible as it makes the code concise.  Here's an example of a pipeline using the general `action` method.
-
-```ruby
-stage "Build" do
-  action(
-    name: "action1",
-    action_type_id: {
-      category: "Build",
-      owner: "AWS",
-      provider: "CodeBuild",
-      version: "1",
-    },
-    run_order: 1,
-    configuration: { project_name: 'demo1' },
-    # output_artifacts: [name: "BuildArtifact#{name}"], # optional
-    input_artifacts: [name: "SourceArtifact"], # default
-  )
-end
-```
-
-{% include prev_next.md %}

data/docs/_docs/dsl/pipeline/codebuild.md

@@ -1,62 +0,0 @@
----
-title: Codebuild Project
-nav_text: Codebuild
-categories: dsl-pipeline
-nav_order: 12
----
-
-The `codebuild` method is one of the most useful methods in the `pipeline.rb` DSL arsenal.  With it, you can add codebuild projects to your pipeline and sequence them quickly.  Let's start with the simplest form.
-
-## String Form
-
-With the String form, the String sets both the name of the CodePipeline Action and CodeBuild Project.
-
-```ruby
-stage "Deploy" do
-  codebuild "demo1"
-  codebuild "demo2", "demo3" # runs in parallel
-  codebuild "demo4"
-end
-```
-
-With just a few lines of code, we have define the pipeline to run the `demo1` codebuild project first.  Then run `demo2` and `demo3` in parallel. Last, run `demo4`.
-
-## Simplified Hash Form
-
-With the Simplified Hash form, we have more control over the CodePipeline Action and CodeBuild Project names.
-
-```ruby
-stage "Deploy" do
-  codebuild(name: "action1", project_name: "demo1")
-  codebuild({name: "action2", project_name: "demo2"}, {name: "action3", project_name: "demo3"}) # runs in parallel
-  codebuild(name: "action4", project_name: "demo4")
-end
-```
-
-In this form, we can explicitly set what the Action Name shows up as in the CodePipeline. We can also set the CodeBuild project name explicitly.
-
-## Full Hash Form
-
-With the Full Hash Form, we have full control of the Action properties.  To keep this example concise, we'll declare only one codebuild Action.
-
-```ruby
-stage "Build" do
-  codebuild(
-    name: "action1",
-    action_type_id: {
-      category: "Build",
-      owner: "AWS",
-      provider: "CodeBuild",
-      version: "1",
-    },
-    run_order: 1,
-    configuration: { project_name: 'demo1' },
-    # output_artifacts: [name: "BuildArtifact#{name}"], # optional
-    input_artifacts: [name: "SourceArtifact"], # default
-  )
-end
-```
-
-The various forms all use ultimately all merge the properties down to the Full Hash Form.  Generally, it is recommended you start with the simplest form and use the more complex forms when required.
-
-{% include prev_next.md %}

data/docs/_docs/dsl/pipeline/prefix-and-suffix.md

@@ -1,57 +0,0 @@
----
-title: Prefix and Suffix Option
-nav_text: Prefix and Suffix
-categories: dsl-pipeline
-nav_order: 13
----
-
-Somewhat interesting options are the `codebuild_prefix` and `codebuild_suffix` option. These options affect the `codebuild` method and allow you to remove some duplication in the pipeline declaration.
-
-## Example
-
-An example helps explain:
-
-Let's say you have 3 codebuild projects that deploy different tiers of the same codebase:
-
-* demo-web-deploy
-* demo-clock-deploy
-* demo-worker-deploy
-
-The setup makes use of 3 codebuild projects, so we have control over deploying each tier separately if desired. Typically, to define this with `pipeline.rb`, it could look something like this.
-
-```ruby
-# Example 1
-stage "Deploy" do
-  codebuild "demo-web-deploy", "demo-clock-deploy", "demo-worker-deploy"
-end
-```
-
-The resulting Action names in the Stage would be a little lengthy and look like this: `DemoWebDeploy`, `DemoClockDeploy`, `DemoWorkerDeploy`. If you wanted to use shorter names like `Web`, `Clock`, and `Worker`, you'd need to use the [Simpified Hash Form]({% link _docs/dsl/pipeline/codebuild.md %}).
-
-```ruby
-# Example 2
-stage "Deploy" do
-  codebuild(
-    {name: "Web", project_name: "demo-web-deploy"},
-    {name: "Clock", project_name: "demo-clock-deploy"},
-    {name: "Worker", project_name: "demo-worker-deploy"}
-end
-```
-
-## Prefix and Suffix Option
-
-If you use the `codebuild_prefix` and `codebuild_suffix`, it'll remove the need to use the Simplified Hash Form.
-
-```ruby
-# Example 3
-codebuild_prefix "demo-"
-codebuild_suffix "-deploy"
-
-stage "Deploy" do
-  codebuild "web", "clock", "worker"
-end
-```
-
-So Example 2 and Examle 3 are equivalent.
-
-{% include prev_next.md %}

data/docs/_docs/dsl/role.md

@@ -1,79 +0,0 @@
----
-title: Role DSL
-nav_text: Role
-categories: dsl
-nav_order: 14
----
-
-The codepipeline tool can create the IAM service role associated with the pipeline. Here's an example:
-
-.codepipeline/role.rb:
-
-```ruby
-iam_policy("logs", "ssm")
-```
-
-For more control, here's a longer form:
-
-```ruby
-iam_policy(
-  action: [
-    "logs:CreateLogGroup",
-    "logs:CreateLogStream",
-    "logs:PutLogEvents",
-    "ssm:*",
-  ],
-  effect: "Allow",
-  resource: "*"
-)
-```
-
-You can also create managed IAM policy.
-
-```ruby
-managed_iam_policy("AmazonS3ReadOnlyAccess")
-```
-
-You can also add multiple managed IAM policies:
-
-```ruby
-managed_iam_policy("AmazonS3ReadOnlyAccess", "AmazonEC2ReadOnlyAccess")
-```
-
-## Full DSL
-
-The convenience methods merely wrap properties of the [AWS::IAM::Role
- CloudFormation Resource](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html).  If you wanted to set the CloudFormation properties more directly, here's an example of using the "Full" DSL.
-
-.codepipeline/role.rb:
-
-```ruby
-assume_role_policy_document(
-  statement: [{
-    action: ["sts:AssumeRole"],
-    effect: "Allow",
-    principal: {
-      service: ["codepipeline.amazonaws.com"]
-    }
-  }],
-  version: "2012-10-17"
-)
-path("/")
-policies([{
-  policy_name: "CodeBuildAccess",
-  policy_document: {
-    version: "2012-10-17",
-    statement: [{
-      action: [
-        "logs:CreateLogGroup",
-        "logs:CreateLogStream",
-        "logs:PutLogEvents",
-      ],
-      effect: "Allow",
-      resource: "*"
-    }]
-  }
-}])
-```
-
-{% include prev_next.md %}

data/docs/_docs/dsl/schedule.md

@@ -1,29 +0,0 @@
----
-title: Schedule DSL
-nav_text: Schedule
-categories: dsl
-nav_order: 15
----
-
-The codepipeline tool supports creating a CloudWatch scheduled event rule that will trigger the codepipeline project periodically.  You define the schedule in `.codepipeline/schedule.rb`. Here's an example of what that looks like:
-
-.codepipeline/schedule.rb:
-
-```ruby
-rate "1 day"
-# or
-cron("0 10 * * ? *") # Run at 10:00 am (UTC) every day
-```
-
-## Full DSL
-
-The convenience methods merely wrap properties of the [AWS::Events::Rule](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-events-rule.html#cfn-events-rule-description).  If you wanted to set the CloudFormation properties more directly, here's an example of using the Full DSL.
-
-.codepipeline/schedule.rb:
-
-```ruby
-description "my description"
-schedule_expression "rate(1 day)"
-```
-
-{% include prev_next.md %}

data/docs/_docs/dsl/sns.md

@@ -1,27 +0,0 @@
----
-title: Sns Topic DSL
-nav_text: Sns Topic
-categories: dsl
-nav_order: 16
----
-
-The codepipeline tool can optionally create an SNS Topic and associate it with your [Approval Action]({% link _docs/dsl/approve.md %}).
-If you have created an Approval Action in the pipeline with the `approve` method, then the codepipeline tool will create and manage the SNS topic for you.
-
-For most cases, the default SNS topic should suffice. However, if you wish to control the SNS topic properties you can do so with a `.codepipeline/sns.rb` file.  Here's an example:
-
-```ruby
-display_name "my display_name"
-kms_master_key_id "String"
-subscription([{
-  endpoint: 'my@email.com',
-  protocol: 'email', # protocol values: https://docs.aws.amazon.com/sns/latest/api/API_Subscribe.html
-}])
-topic_name "string", # Recommend not setting because update requires: Replacement. Allow CloudFormation to set it so 2 pipelines dont have same SNS Topic name that collides
-```
-
-The methods in the `sns.rb` are simply properties of the [SNS::Topic](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-sns-topic.html) CloudFormation Resource
-
-Note: The codepipeline tool will only create the SNS Topic if you have declared an Approval Action in the `pipeline.rb` without specifying an existing SNS Topic ARN.
-
-{% include prev_next.md %}

data/docs/_docs/dsl/webhook.md

@@ -1,31 +0,0 @@
----
-title: Webhook DSL
-nav_text: Webhook
-categories: dsl
-nav_order: 17
----
-
-The simplest way to declare a webhook is to use the `github_token` method. This single line is enough to configure and set up the webhook.
-
-.codepipeline/webhook.rb:
-
-```ruby
-github_token(ssm("/codebuild/github/oauth_token"))
-```
-
-## Full DSL
-
-The convenience methods merely wrap properties of the [AWS::CodePipeline::Webhook](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codepipeline-webhook.html).  If you wanted to set the CloudFormation properties more directly, here's an example of using the Full DSL.
-
-.codepipeline/webhook.rb:
-
-```ruby
-authentication "GITHUB_HMAC"
-authentication_configuration(secret_token: ssm("/codebuild/github/oauth_token"))
-filters([{
-  json_path: "$.ref",
-  match_equals: "refs/heads/{Branch}",
-}])
-```
-
-{% include prev_next.md %}

data/docs/_docs/ecs-deploy.md

@@ -1,22 +0,0 @@
----
-title: 'ECS Deploy: Codebuild ufo ship vs CodePipeline ECS Deploy'
-nav_order: 21
----
-
-CodePipeline comes with many [Action Type Integrations](https://docs.aws.amazon.com/codepipeline/latest/userguide/integrations-action-type.html).  One of the Integrations is [Amazon Elastic Container Service](https://docs.aws.amazon.com/codepipeline/latest/userguide/integrations-action-type.html#integrations-deploy) deployment. It is recommended to use [codebuild and ufo](https://codebuild.cloud/docs/examples/ecs/) to handle deployment to ECS though.  We discuss some reasons below.
-
-## Timeout
-
-With the CodePipeline ECS Deploy if your ECS service fails to stabilize then the pipeline stage will not timeout until 60 minutes later. There is no built-in way to abort the pipeline stage. This is discussed here: [CodePipeline stage timeouts / abort?](https://forums.aws.amazon.com/thread.jspa?threadID=216350).
-
-A workaround is discussed here: [How to stop an execution or set set timeout for an action in AWS CodePipeline?](https://stackoverflow.com/questions/50925732/how-to-stop-an-execution-or-set-set-timeout-for-an-action-in-aws-codepipeline/50929558). So to workaround waiting for 60 minutes, we can update the pipeline. This is a little bit inconvenient.
-
-By using a codebuild project, we have control over the timeout.
-
-## It's Less Powerful
-
-The way the current CodePipeline ECS Deploy Action works is that it pulls down the current ECS task definition that ECS service is using. It then replaces the image property on it. Last, it then updates the ECS service with the newly built Docker image.
-
-The [ufo tool](https://ufoships.com) is more powerful.  The `ufo ship` command also handles creating the [ELB Load Balancer]((https://ufoships.com/docs/extras/load-balancer/)) and a vanity [Route53 endpoint](https://ufoships.com/docs/extras/route53-support/) for us.  Also, it keeps task definitions codified.
-
-{% include prev_next.md %}

data/docs/_docs/examples/codebuild-project.md

@@ -1,21 +0,0 @@
----
-title: Create CodeBuild Project
-nav_text: Create CodeBuild
-categories: examples
-nav_order: 18
----
-
-It is common to use codebuild as a Stage Action in the pipeline. Here's are instructions to quickly create a codebuild project.
-
-We'll use the [codebuild.cloud](https://codebuild.cloud) tool to help with this. Here are the commands.
-
-    cb init # generates starter .codebuild files including the buildspec.yml
-    # commit and yours the .codebuild files
-    git add .codebuild
-    git commit -m 'add .codebuild files'
-    git push
-    pipe deploy demo # creates a codebuild project
-
-There's also an example where we quickly create 4 test codebuild projects here: [Multiple CodeBuild Projects](https://codepipeline.org/docs/examples/multiple-codebuild-projects/).
-
-{% include prev_next.md %}

data/docs/_docs/examples/different-branches.md

@@ -1,49 +0,0 @@
----
-title: Using Different Branches
-nav_text: Different Branches
-categories: examples
-nav_order: 19
----
-
-CodePipeline currently does not supports starting the pipeline execution with different branches natively. To get around this, we can:
-
-1. update the pipeline before starting it.
-2. create additional pipelines.
-
-The codepipeline tool supports both methods.
-
-## Update Pipeline Approach
-
-With the update pipeline approach, the pipeline gets updated if the current pipeline branch is different from the requested branch before a pipeline execution starts. Examples:
-
-    pipe start -b master
-    pipe start -b qa
-
-Note: With this approach, since the pipeline gets updated, the pipeline will maintain the last branch it was started with.
-
-## Multiple Pipelines Approach
-
-You might normally set the branch option in your pipeline.rb. Example:
-
-```ruby
-stage "Source" do
-  github(
-    source: "user/repo",
-    auth_token: ssm("/github/user/token")
-  )
-end
-```
-
-When we deploy to create the pipelines, we can explicitly specify the branch to use. The cli option overrides the branch specified in `pipeline.rb`. Examples:
-
-    pipe deploy demo-master -b master
-    pipe deploy demo-qa -b qa
-
-This creates 2 pipelines. The demo-master pipeline will use the master branch, and the demo-qa pipeline will use the qa branch.
-
-To start the pipelines:
-
-    pipe start demo-master
-    pipe start demo-qa
-
-{% include prev_next.md %}

data/docs/_docs/examples/multiple-codebuild-projects.md

@@ -1,60 +0,0 @@
----
-title: Multiple CodeBuild Projects
-nav_text: Multiple CodeBuild
-categories: examples
-nav_order: 20
----
-
-In this example guide, we'll create a couple of test CodeBuild projects and quickly connect them up to a pipeline.
-
-## CodeBuild Projects
-
-We'll use the the [codebuild](https://codebuild.cloud/) tool to quickly get going.
-
-You can use any project, even an empty folder. You just have to make sure it is first pushed to GitHub.  If you need an example project, you can try this one: [tongueroo/demo-ufo](https://github.com/tongueroo/demo-ufo).
-
-First, you can use `cb init` create some starter ``.codebuild` files.
-
-    cd init
-    git add .
-    git commit -m 'add starter .codebuild files'
-    git push
-
-Then create the 4 CodeBuild projects for testing:
-
-    for i in 1 2 3 4 ; do pipe deploy demo$i --no-wait ; done
-
-## CodePipeline
-
-Let's define a pipeline now with the 4 CodeBuild test projects. First, use `pipe init` to create the starter `.codepipeline` files. Update your `pipeline.rb` with the following:
-
-codepipeline/pipeline.rb:
-
-```ruby
-stage "Source" do
-  github(
-    source: "tongueroo/demo-ufo", # replace with your repo
-    auth_token: ssm("/github/user/token")
-  )
-end
-
-stage "Build" do
-  codebuild "demo1"
-  codebuild "demo2", "demo3" # runs in parallel
-  codebuild "demo4"
-end
-```
-
-Deploy it with:
-
-    pipe deploy
-
-Last, start the pipeline execution:
-
-    pipe start
-
-That's it!  The pipeline will look like this:
-
-![](/img/docs/multiple-codebuild-projects-pipeline.png)
-
-{% include prev_next.md %}