Add automatic deployment to blue server

[upkarlidder]

Background on the problem the feature will solve/improved user experience

Add GitHub actions to deploy solution to blue site whenever code is pushed to the blue branch. The action will first call build-ui, build-services and any other actions needed for successful build.

Describe the solution you'd like

Create an action that deploys the ui and services components to the cloud using cloud foundry

Tasks

@davidnixon I am testing in a more simplistic sample repo and this works well

.github/workflows/deploy-blue-cf.yml

name: Deploy Blue CF

on:
  push:
    branches:
    - blue
  pull_request:
    branches:
    - blue

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Deploy to IBM Cloud Foundry
        # You may pin to the exact commit or the version.
        uses: IBM/cloudfoundry-deploy@master
        with:
          IBM_CLOUD_API_KEY: ${{ secrets.IBM_CLOUD_API_KEY }}
          IBM_CLOUD_CF_API: ${{ secrets.IBM_CLOUD_CF_API }}
          IBM_CLOUD_CF_ORG: ${{ secrets.IBM_CLOUD_CF_ORG }}
          IBM_CLOUD_CF_SPACE: ${{ secrets.IBM_CLOUD_CF_SPACE }}
          APP_VARS_FILE: ${{ secrets.APP_VARS_FILE }}

blue.yml (customize build for the blue environment)

name: cicdnodedelete-blue
memory: 64M

manifest.yml (adding variables that will be picked up from blue.yml) @davidnixon this is problematic as you will have to change the existing build perhaps? Can you create production.yml for vars and use that in tekton pipelines with the --vars-file argument? Alternatively I can just create manifest-blue.yml and not touch the existing manifest file. Learning more towards the latter.

---
applications:
- instances: 1
  timeout: 180
  name: ((name))
  buildpack: nodejs_buildpack
  command: npm start
  random-route: true
  memory: ((memory))
  env:
    OPTIMIZE_MEMORY: true

Acceptance Criteria

GitHub action that deploys to the blue server whenever code is pushed to the blue branch.

[davidnixon]

With this trigger:

on:
  push:
    branches:
    - blue
  pull_request:
    branches:
    - blue

I think any PR that targets the blue branch will trigger a deployment. I think you just want the push and remove the pull_request section.

What do you think of using a prerelease as a trigger instead of a push to the blue branch?

on:
  release:
    types: [prereleased]

You could use the existing manifest files and specify more options on the command line. The command line take precedence over what is in the manifest. So for example:

cd ui
ic cf push cicdnodedelete-blue -m 64m

That will use the manifest.yml in the ui dir but the app name will be cicdnodedelete-blue and the memory will be 64mb.

I am looking at IBM/cloudfoundry-deploy and it does not support command line params so if you want to use that then it seems the best option is to create a manifest-blue.yml file.

The other options would be:

1. copy the inputs and steps from IBM/cloudfoundry-deploy into your action and remove uses: IBM/cloudfoundry-deploy@master
2. Fork IBM/cloudfoundry-deploy and add support for more command line options in your fork and then use that
3. create a production.yml as you suggest above and use that with a vars file for cicdnodedelete-blue. Once your "blue" workflow is working we can move the production site deployment to a git action that uses your same workflow source with different vars.

[github-actions[bot]]

:wave: Hi! This issue has been marked stale due to inactivity. If no further activity occurs, it will automatically be closed.

[github-actions[bot]]

:wave: Hi! This issue has been marked stale due to inactivity. If no further activity occurs, it will automatically be closed.

[upkarlidder]

Completed. Closing issue.