Better support for cloud.gov Service Accounts

[rogeruiz]

Because of cloud.gov Service Accounts being scoped to an org and space, the cf_deploy.sh shouldn't require an org or space in order to better enforce deployments using these cloud.gov Service Accounts.

Documentation in the Read Me should also talk about how to set multiple credentials in CircleCI for different deploying to separate spaces since cloud.gov Service Accounts can no longer be shared across spaces.

[adborden]

Because of cloud.gov Service Accounts being scoped to an org and space, the cf_deploy.sh shouldn't require an org or space in order to better enforce deployments using these cloud.gov Service Accounts.

I'm not sure what you mean by this... don't we have to tell cf an org/space at some point?

Do you have an example of how you worked around managing the multiple deployer accounts? I was thinking (and I could add this to the docs) you would add multiple env variables in the Circle UI, DEPLOYER_STAGE_USER, DEPLOYER_STAGE_PASS, DEPLOYER_DEV_USER, DEPLOYER_DEV_PASS, etc. Then in the configuration or command, you would map them to the variables as expected.

jobs:
  build:
    docker:
      - image: 18fgsa/cloud-foundry-cli
        environment:
          CF_API: https://api.fr.cloud.gov
          CF_DEPLOY_USER: $DEPLOY_STAGE_USER
          CF_DEPLOY_PASS: $DEPLOY_STAGE_PASS
    steps:
      - checkout
      - run:
          name: Your build step
          command: ./build.sh
      - deploy:
          name: cf push
          command: cf_deploy.sh app-name org-name space-name

or

      - deploy:
          name: cf push
          command: cf_deploy.sh app-name org-name space-name
          environment:
            CF_DEPLOY_USER: $DEPLOY_STAGE_USER
            CF_DEPLOY_PASS: $DEPLOY_STAGE_PASS

[rogeruiz]

Yeah, those examples are great. We should have them in the readme. But with the cloud.gov Service Accounts, the user is scoped to the org and space, so there's no need to make these scripts aware of the org and space as the user accounts brokered can't move freely. They're tied to the space the service is created in which also ties it to that org as spaces can't live outside of orgs.

This would probably get cleared up once #11 gets addressed. I like the idea of this image only containing the plugins we need and becoming more of a Bring Your Own Scripts with either examples or scripts folks could call if they really wanted to not write anything custom.

[adborden]

Maybe this is my lack of understanding of cloud foundry, so you're saying that the Service Account doesn't need to run cf target? cf push will push the application to the Service Account's org/space automatically?

[rogeruiz]

@adborden yup! 👍