Amplify-cli: How to re-init existing project

[jadbox]

I've already set up a project in github that uses Amplify cli to create an Auth service. However when I pull down the project on another computer, running init again seem to create a new project. With awsmobile, I could run awsmobile init my-project-id to set up the project on a new machine. How do I reuse the same setup [in this case, a specific Cognito service] when pulling down my project on another machine?

Another related question, if I already have an existing Cognito service that I created manually, how could I tell amplify-cli to use it for the auth service?

[UnleashedMind]

Currently the amplify cli init does not have the ability to link to an existing backend project, so the awsmobile init project-id workflow is not available.
Current the auth category does not allow you to use an existing cognito service that you configured on the console.
I will mark these as feature requests.

[jadbox]

@UnleashedMind okay thanks. I'll stick to awsmobile-cli for now as I need to work with existing Cognito services.

[kaustavghosh06]

@jadbox

We're currently brainstorming and working towards providing a CI/CD workflow as a part of the Amplify CLI, and in doing so we want to work backward from the customer needs and we've opened up an issue (#286) as a part of the CLI repo to track this story.
Would be great, if you guys could take a look at it and respond back with some answers to the questions mentioned in the issue (#286) which would give us a better idea about your needs. Thanks!

[rizerzero]

@jadbox Hi, did you find a solution or a workflow that works for you ?

[kaustavghosh06]

@rizerzero We're actively working right now on making inter-team and intra-team workflows, and CI/CD workflows better as a part of the Amplify CLI (based upon our RFC #286) which should solve this issue and make your experience of re-initing an existing project and sharing of a project within teams simpler.

[lestephane]

Here are some thoughts that occurred to me while running into this issue today.

Everything in .amplifyrc could be moved to SecureString parameters in hierarchical SSM parameter store paths named after a UUID for the amplify project, something like:

"/amplify/{PROJECT_UUID}/providers/awscloudformation/AuthRoleName" = "{PROJECT_NAME}amplify-20181120085721-authRole",
"/amplify/{PROJECT_UUID}/providers/awscloudformation/UnauthRoleArn" = "arn:aws:iam::{ACCOUNT_ID}:role/{PROJECT_NAME}amplify-20181120085721-unauthRole",
"/amplify/{PROJECT_UUID}/providers/awscloudformation/AuthRoleArn" = "arn:aws:iam::{ACCOUNT_ID}:role/{PROJECT_NAME}amplify-20181120085721-authRole",
"/amplify/{PROJECT_UUID}/providers/awscloudformation/DeploymentBucketName" = "{PROJECT_NAME}amplify-20181120085721-deployment",
"/amplify/{PROJECT_UUID}/providers/awscloudformation/UnauthRoleName" = "{PROJECT_NAME}amplify-20181120085721-unauthRole",
"/amplify/{PROJECT_UUID}/providers/awscloudformation/StackName" = "{PROJECT_NAME}amplify-20181120085721",
"/amplify/{PROJECT_UUID}/providers/awscloudformation/StackId" = "arn:aws:cloudformation:eu-central-1:{ACCOUNT_ID}:stack/{PROJECT_NAME}amplify-20181120085721/8761d970-ec91-11e8-ab01-021298c8e4cc"

(remove providers/awscloudformation if you only ever will have awscloudformation related parameters, but at 1011 characters and 15 levels maximum for a full ssm parameter path name, i think we can go as deep as we need)

Once you have that, the .amplifyrc can be shrunk to:

{
  "ProjectUuid": "{generated uuid}",
  "Region": "{region must be here, since it needs to be known when accessing the SSM parameter store}" 
}

Amplify init could be so configured that it looks up everything it needs from the SSM, so the .amplifyrc no longer contains sensitive information, and can be commited to version control if desired, based on the development model.

• Model 1: the ProjectUuid could be generated from git origin + branch if you wish to enforce the one-branch, one-deployed amplify project paradigm, with the .amplifyrc committed into git, but recoverable from the git origin + branch if it's not.
• Model 2: the ProjectUuid could be generated completely randomly if you wish to have a one-branch, multiple-deployed amplify projects paradigm, with the developer responsible to managing his .amplifyrc.

I'm assuming Model 1 for the sake of this discussion.

The SSM parameters are only the first part of the solution. After that, we need to solve the problem of who is allowed to access the SSM parameters. I would suggest using an IAM role under a path as well (max length for an IAM role path is 512 and IAM role name is 64 characters, which is hopefully sufficient). At initial amplify init, a new role would be created under a path that uses the same scheme as SSM parameters:

/amplify/{PROJECT_UUID}/InitRoleArn

Having these two moving parts, 're-init' is no longer necessary in Model 1:

• developer dev1 runs the initial amplify init
• amplify init creates the SSM parameters and IAM InitRole
• dev1 commits the .amplifyrc to git
• in time, another developer dev2 clones the repo
• dev2 types an amplify {command} that needs to access the SSM configuration
• the amplify cli uses the IAM api to look for the role /amplify/{PROJECT_UUID}/InitRoleArn (where PROJECT_UUID comes from the .amplifyrc file
• if the role is not found (or invisible to dev2's current credentials), the amplify cli command fails with a helpful message containing the role that it failed to find, suggesting that the project is no longer initialized and connected to the cloud OR that the current credentials do not allow the user to run amplify commands on that project.
• if the role is found, the amplify cli command attempts to assume the role using dev2's current credentials
• if the role assumption fails, the amplify cli command fails with a helpful message containing the role that it failed to assume, and a hint that dev2 should contact his admin to be allowed to assume that role.
• if the role assumption succeeds, the amplify cli now has access to all the information it needs from the SSM parameter store under /amplify/{PROJECT_UUID}/* paths (there's a get-parameters-by-path capability in the SSM api).

An additional failsafe to avoid more support issues later:

• if the command is amplify init AND the .amplifyrc is _already present_, fail with a message that the problem is already initialized. At the moment, If i run the init command twice, i get two CloudFormation stacks, and the previous one is dangling like an orphan. This is why i came to enter this issue today.

[kaustavghosh06]

@lestephane Just to give you an idea, we're close to complete with the beta version of team-workflows and CI/CD flows as part of the Amplify CLI and working actively on our documentation. As soon as we launch it, I'll update this thread (expect an announcement sometime next week).

This release should answer all your questions above. Seems like we've taken into considerations all your above recommendations :)

[kaustavghosh06]

Based on all of your feedback, we’ve released a beta version of the CLI (npm install -g @aws-amplify/cli@multienv) to support multiple environments, team workflows and integrate with your CI/CD flows.
Please check out this documentation for more details - https://aws-amplify.github.io/docs/cli/multienv?sdk=js
Also, as a part of our feedback mechanism, we’ve opened up another GitHub issue, to track feedback from everyone, iterate on this beta version and then merge it to master. We'll close this issue and track feedback in #508. Looking forward to your feedback on this release.

[kaustavghosh06]

Closing this issue since this problem is solved with the release of the multienv feature-set mentioned above.

[EralpB]

I'm assuming this is still the case after 2 years, I can't just send an "id" to my app developer to start a project....

[byennen]

broken again

[tvkit]

I mistakenly selected the wrong IAM profile which resulted in "access denied". I used the following Amplify settings from _.gitignore_ to determine how to rerun the init process:

I basically removed the Amplify artifacts not tracked by git.

Zip your project before making changes!

#amplify
amplify/\#current-cloud-backend
amplify/.config/local-*
amplify/mock-data
amplify/backend/amplify-meta.json
amplify/backend/awscloudformation