Autodeploy deploying into wrong account

[dhoulker]

I've raised this in Discord, but raising here as well incase any else has the same problem and can help.

We are running into a strange issue with autodeploy. We have 4 environments, mapped to 3 AWS accounts (pr's and dev go to dev account) When we merge into production, the deploy runs, but it deploys into the dev account. I think my SST config is correct as i can see sst deploy --stage prd running in the logs when i merge into prod branch.

In the screenshot, you can see the 4 environments, but prd deploy does not deploy to expected account. I'm sure i'm missing something obvious here, how can i debug it?

You can see below the merge into production triggers sst deploy --stage prd

I'm sure i'm doing something wrong, but i'm not sure how to debug this further, does anyone have idea what could be going wrong or steps i can follow to find out whats happening?

Thanks!

[jayair]

Following up there for now

[dhoulker]

Thanks @jayair - the console channel has been archived, so i can't respond there. You asked:

"So from the second screenshot here, it's saying that it's deploying to a stage called prd. Now if you go to the app page where it lists all the stages, what's the AWS account listed by prd?"

What happened was we ended up with two prd stages there.

1. Deployed by autodeploy to the wrong account
2. The one we deploy manually with sst deploy --stage prd locally, as it was the only route to production

I had to kill the the first one by setting my terminal profile to dev, then running sst remove --stage prd

Like I say, sure i'm doing something wrong just not sure how to debug.

We removed the AWS prod account from the console and re-added, but same thing just happened again.

[jayair]

Do you have an auto deploy block in your sst config?

[dhoulker]

I do - i assumed this was not the issue as i can see sst deploy --stage prd when merging into the production branch, however maybe i'm wrong.

It looks like this:

console: {
  autodeploy: {
	target(event) {
		// staging -> stg
		if (
			event.type === "branch" &&
			event.branch === "staging" &&
			event.action === "pushed"
		) {
			return { stage: "stg" };
		}
		// production -> prd
		if (
			event.type === "branch" &&
			event.branch === "production" &&
			event.action === "pushed"
		) {
			return { stage: "prd" };
		}
		// dev -> dev
		if (
			event.type === "branch" &&
			event.branch === "dev" &&
			event.action === "pushed"
		) {
			return { stage: "dev" };
		}

		// only create a stage for PRs that are targeting the dev branch
		if (event.type === "pull_request" && event.base === "dev") {
			return { stage: `pr${event.number}` };
		}
	},
  },
},
	```

[dhoulker]

Hi @jayair, any ideas on what else i can try here? Do you see any issues with my config above?

[jayair]

So is prd supposed to deploy to a stage with the id ending in 414?

[dhoulker]

Yes, thats correct.

[jayair]

Just to double check, given the above config if you push to your production branch, does it trigger a deploy to the prd stage with the 414 account?

[dhoulker]

Thanks for coming back to this for us.

So the expected behaviour is that it triggers a deploy into the 414 account, but the actual behaviour is a deploy into the 736 account.

We disconnected the prod account from the console and started again (a while back now) but the same thing happend.

Is there anything else we can try to reset things?

[jayair]

Ah I see. The pr* is getting matched. Can you instead try something like pr-*?

[dhoulker]

AH! That makes sense thank you, understand whats happening now. The reason we moved from pr-123 to pr123 is because the stage name often makes its was into AWS names, and AWS has different rules on what it allows. It does not allow - for something we do (might be IOT rules, can't remember) so we took it out.

I guess we need to think about an alternative naming, but now i know whats going on we can work on that. Thanks again for all your support with it.