Add option to override resolve_s3 from samconfig

[ExtremoPenguin]

Describe your idea/feature/enhancement

If samconfig sets resolve_s3 there is no way to override this setting using command line arguments. There should be the option to clear this flag using the command line arguments so that --s3-bucket can be used instead when needed.

Proposal

Add the option to pass --resolve-s3 false on the CLI which would be the equivalent of not setting --resolve-s3 at all.

Additional Details

We try to setup our projects so that developers can stand up our applications in their own sandbox accounts with same settings that our CI builds use when deploying to production environments. samconfig has been very useful for that as we can move most of the CLI arguments to configuration that is checked into git. Developers deploying to their test environments can then simply run sam deploy without needing to copy and paste a bunch of CLI arguments.

The issue we are running into is that for developer environments, using resolve_s3 in samconfig works great and automatically detects the SourceBucket from the aws-sam-cli-managed-default stack. But in our CI pipelines, we are using the user and role generated from sam pipeline bootstrap which has its own artifact bucket and does not have permissions to the bucket in aws-sam-cli-managed-default. This means we need to specify --s3-bucket in the CI environments. But because --resolve-s3 is a flag, it can not be unset and using --s3-bucket throws an error since resolve-s3 and s3-bucket are mutually exclusive.

The work around is fairly minor. Just don't include resolve_s3 in samconfig and require developers include it as a command line argument when running sam. But it would be nice if everything set in samconfig could be overridden by the CLI arguments when needed.

[lucashuy]

Thanks for opening this feature request. It looks like the inverse of the flag needs to be configured (ie. --no-resolve-s3) so that your desired behaviour is achieved. Let me raise this with the team for prioritization and to see if this aligns with what we wanted to do with this option.

In the mean time, I'm going to mark this as a good first issue for folks that wanted to contribute to this project.

[nitintecg]

@lucashuy I would like to contribute this issue. I'm having doubt that new option--no-resolve-s3 will ignores resolve-s3 option if its present. for eg like this in deploy command.py file

if not no_resolve_s3 and resolve_s3: # here means resolve_s3 will be supported when no_resolve_s3 is not present
            if bool(s3_bucket):
                raise DeployResolveS3AndS3SetError()

am i right here ?

[lucashuy]

Hi @nitintecg, this would actually be something that is changed in the existing click option, as opposed to a new option or flag. The click documentation for this behaviour can be found here: https://click.palletsprojects.com/en/8.1.x/options/#boolean-flags, and an example of how we do this with a different flag in our code can be found here:

aws-sam-cli/samcli/commands/_utils/experimental.py

Lines 187 to 196 in c6b1155

	def experimental_click_option(default: Optional[bool]):
	return click.option(
	"--beta-features/--no-beta-features",
	default=default,
	required=False,
	is_flag=True,
	expose_value=False,
	callback=_experimental_option_callback,
	help="Enable/Disable beta features.",
	)

Since resolve_s3 is a boolean, we can just use the same variable by updating the existing option.

[lucashuy]

The place where we define our --resolve-s3 flag can be found here:

aws-sam-cli/samcli/commands/_utils/options.py

Lines 739 to 748 in 0849b2a

	return click.option(
	"--resolve-s3",
	required=False,
	is_flag=True,
	callback=callback,
	help="Automatically resolve AWS S3 bucket for non-guided deployments. "
	"Enabling this option will also create a managed default AWS S3 bucket for you. "
	"If one does not provide a --s3-bucket value, the managed bucket will be used. "
	"Do not use --guided with this option.",
	)

The changes here should be adding the inverse to the flag, and updating/adding any new unit tests to validate that the new inverse doesn't break anything.

Integration tests that actually deploy resources can be run too, but incurs any related AWS costs. The team can help out with running or writing these tests when you're ready for that.