Hey guys, still working on some IAM issues I’m having to enable our branch and main deployments in serverless. I’m wondering if there may be a bug. I’ve created some IAM roles that are assumed as a resource during runtime, however, I’m having issues passing the base user to the deployments. To attempt to do this, I’m setting the repos AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in the repo secrets to a low-priv user “dagster_user”. However, this ends up failing with the following error:

Dockerfile:44
--------------------
  42 |     ENV DAGSTER_CLOUD_URL=***
  43 |     ENV ACTIONS_STEP_DEBUG=true
  44 | >>> ENV AWS_ACCESS_KEY_ID= *** 
  45 |     
--------------------
ERROR: failed to solve: Syntax error - can't find = in "***". Must be of the form: name=value
Error: buildx failed with: ERROR: failed to solve: Syntax error - can't find = in "***". Must be of the form: name=value

Further up above, we see that the env_var dictionary that is constructed also adds this extra whitespace to AWS_ACCESS_KEY_ID and not to any other fields.

##[debug]  "AWS_SECRET_ACCESS_KEY": "***",
##[debug]  "DAGSTER_CLOUD_URL": "***",
##[debug]  "ACTIONS_STEP_DEBUG": "true",
##[debug]  "AWS_ACCESS_KEY_ID": " *** "

I’ve checked and my secret itself has no whitespace in it. Any assistance here would be great 🙂, also perhaps confirmation regarding if serverless users should be passing envs in this manner, and if not, what the ‘best practice’ alternative is

Hi Zach - that looks right to me, but the extra whitespace is decidedly unexpected... we'll take a look. env_vars is generated by JSON encoding the secrets dict and then JSON decoding it back into a dict. Without revealing the exact value of the AWS_ACCESS_KEY_ID secret of course, is there anything unique about it that might explain why the weird whitespace could be being added? Starting with an unusual character? Feels like we might be hitting some json-parsing-within-github-actions edge case. Dunno if this is a situation where you could generate a new key and revoke the old one to make it more shareable, but if it is, having the exact value would probably make reproducing this a lot easier

I’ll try regenerating it!

ahhhh mystery solved