Describe the bug
I configured 2 environments for a project I'm building. Dev and Master using the same patterns described in the multi-env doc page. I have not done anything with the master environment for a couple of weeks and now it is no longer showing up when I type amplify env list
. amplify env get --name master
returns No environment found with the corresponding name provided
To Reproduce
I've not reproduced this since but here's what happened
Steps to reproduce the behavior:
amplify env add
to add a new environmentamplify env list
Expected behavior
I'd expect to see both the dev and the new env I created in the list
Observed Behavior
$ amplify env get --name master
No environment found with the corresponding name provided
All of the resources for that environment are still running - S3 buckets, API and Elasticsearch instances. I just can't control them anymore.
Desktop (please complete the following information):
Smartphone (please complete the following information):
Additional context
Add any other context about the problem here.
BTW - I find this very disconcerting and I am getting nervous about deploying on this platform when I lose the ability to manage it after a week or so between this issue and the chain of errors described in #980
@poppybank The envs are managed locally in your filesystem and shouldn鈥檛 disappear if your local filesystem hasn鈥檛 updated or changed in a week. Could you please check your amplify/team-provider-info.json file to check if you have keys corresponding to each of your envs?
Thanks @kaustavghosh06. Only the dev environment is in the amplify/team-provider-info.json file.
Honestly I was expecting that these items would be stored in the cloud. Is there a way to rebuild the awscloudformation data if that version of the team-provider-info.json has been lost?
@poppybank If you didn't check in your team-provider-info.json file in a VCS before you lost the reference to it, you could retrieve the "awscloudformation" information from the that environments corresponding to that environment from the parent Cloudformation stack (in the Outputs section) in the AWS Cloudformation console.
You can copy-paste this info in the amplify/team-provider-info.json file (use your other enviornment as a reference) and then "amplify init" the project and select the environment that you just added to initialize and use the environment you just added to your team-provider-info.json file.
Once I add this information into amplify/team-provider-info.json as a second env, I would want to do amplify env checkout <envname>
then right? The project already has been inited. Or is amplify init preferred over checkout if I'm just switching which environment I'm targeting?
When you amplify init
, the CLI would ask you if you want to use an already exisiting environment and you would get a list of envs to choose from. You could alternatively use amplify env checkout <envname>
as you've mentioned above which would do the same thing.
@kaustavghosh06 Thanks that help. The word init
(to me) means it is configuring something for the first time so it would seem bad to do this with an enlistment that is already running.
One last question on the multi-env functionality, then. If I have an unattended build machine that needs to build my mobile apps, the build machine would need to have amplify installed but then it would checkout a branch from git and run amplify env checkout <envname>
and would it then be ready to build or would it also need to run amplify api gql-compile
to have the tree configured for a build?
This process needs to run unattended so things like amplify init
won't work well here.
Thanks
@poppybank That's exactly why we support headless mode for our commands like init/push/publish etc so that these commands could be run on build systems.
Please take a look at https://aws-amplify.github.io/docs/cli/init#headless-usage-of-the-cli for more information around this.
I was sure you had it solved, just hadn't seen that documentation yet. thanks!!
@kaustavghosh06 I made a change to the graphql.schema and did amplify push
but the files in src/graphql are not being updated to reflect that I removed a @model declaration. Is there a way to force rebuild those? Doing amplify api gql-compile
does not seem to do it.
@poppybank Since this question is not tied to this specific issue, could you please open another issue for this or reference me in the issue if you'e already opened for this?
@poppybank did you get rid of the model, or change its name?
I did not change its name. I did try removing a model (comments) and did amplify push
when the @searchable thing was failing. That left comments in a state with the resolvers deleted but nothing else was gone even though the amplify push
was rolled back
amplify pull --appId [APP_ID_HERE] --envName [ENV_NAME_HERE]
did the trick for me.
Most helpful comment
@poppybank If you didn't check in your team-provider-info.json file in a VCS before you lost the reference to it, you could retrieve the "awscloudformation" information from the that environments corresponding to that environment from the parent Cloudformation stack (in the Outputs section) in the AWS Cloudformation console.

You can copy-paste this info in the amplify/team-provider-info.json file (use your other enviornment as a reference) and then "amplify init" the project and select the environment that you just added to initialize and use the environment you just added to your team-provider-info.json file.