Amplify-console: Support multiple apps in monorepo with amplify.yml file

Created on 22 Jan 2020  路  11Comments  路  Source: aws-amplify/amplify-console

Is your feature request related to a problem? Please describe.
I use a monorepo which hosts multiple frontends with a single backend. I would like to keep all configuration in source control, but amplify.yml is not extensible enough to work against multiple frontends. Specifically, for frontend builds the artefacts baseDirectory takes a location string , which each frontend would need a different path.

Describe the solution you'd like

  1. Allow an environment variable to specify the amplify.yml path in the console, OR
  2. Allow each section of the amplify.yml file to have a key for the name of the app, so that I can specify a baseDirectory for each named app. Example: { "artifacts": {"baseDirectory": {"app1": "/package/app1/build", "app2": "/package/app2/build" } } }

Additional context
I understand I can remove the amplify.yml file from the root directory and paste a configuration for each app inside each AWS account, but this is not fun to manage with 15+ combinations of apps/accounts, and it doesn't get versioned for easy environment setups.

feature request

Most helpful comment

We also NEED this feature. My current work around is to have multiple front end apps pointed at the same monorepo. Then each app build specifies an ENV variable, which I use inside the amplify.yml file to build/deploy the correct application. However, the downside is that a change to any of the apps/packages in the monorepo triggers ALL the apps/packages to build and deploy. This causes many un-needed builds/deploys. And it reeks havoc on our versioning of each app/package.

All 11 comments

@RossWilliams thanks for the request. There is a present workaround. Amplify Console has system variables you could leverage such as AWS_APP_ID. You could do something like

artifacts:
      baseDirectory:
        - if [ "${AWS_APP_ID}" = "XXXXXX" ]; then /package/app1/build ; fi

We are looking at improving our monorepo support by adding support for selective build triggers, autodetection of monorepos. Let me know if there are any other asks.

@swaminator I have not been successful implementing your suggestion, nor variants to echo the response, or even a simple case which removes the condition statement.

The documentation states frontend -> artefacts -> baseDirectory is of type "location". Attempting to use a script array as an argument results in the following console error for all variants tested:

2020-02-06T13:18:41.803Z [WARNING]: !TypeError: Cannot read property 'paths' of undefined
2020-02-06T13:18:41.807Z [ERROR]: !!! TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string

We also NEED this feature. My current work around is to have multiple front end apps pointed at the same monorepo. Then each app build specifies an ENV variable, which I use inside the amplify.yml file to build/deploy the correct application. However, the downside is that a change to any of the apps/packages in the monorepo triggers ALL the apps/packages to build and deploy. This causes many un-needed builds/deploys. And it reeks havoc on our versioning of each app/package.

To add on for what I'd like for my purposes. It would be helpful if we could have the build/deploy trigger not just on a push to the repo, but also be allowed to filter on the directory that push happened. That is possible in the AWS CodeBuild tool, but it's not quite right for our needs either.

@jonvanausdeln Why don't you set up different git branches for each app/package within your mono repo and setup different Amplify environments for each branch?

This is what I currently do. I have the following branches:

  • app1-staging
  • app1-prod
  • app2-staging
  • app2-prod

@RossWilliams as a workaround till Amplify will support variables in the baseDirectory i added a command to the postBuild stage that copy the relevant app files into a directory specific for that and I just added that directory to the baseDirectory path.

Any updates on this @swaminator ?

@swaminator looks like this got released, thanks!

@RossWilliams What was released to support it?

@RossWilliams @jonvanausdeln @simpson as @RossWilliams highlighted we just released support for this. Please open a new issue if you have anything to report with respect to it.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

nballenger picture nballenger  路  5Comments

hassankhan picture hassankhan  路  4Comments

adamaltman picture adamaltman  路  3Comments

thedgbrt picture thedgbrt  路  5Comments

JIoJIaJIu picture JIoJIaJIu  路  5Comments