-
Notifications
You must be signed in to change notification settings - Fork 619
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
create envfile task resource #2398
Conversation
this commit initializes the environment files resource when task starts up, and reads the environment variables from those files when containers are created
gocyclo fails on |
agent/api/container/container.go
Outdated
// envVarsList is a list of map, where each map is from an envfile | ||
// iterate over this sequentially because the original order of the | ||
// environment files give precedence to the environment variables | ||
for _, envVarsIn := range envVarsList { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any repeated variable in more than one env file needs to be resolved by precedence as well, in the order as defined in the "environmentFiles" list. I don't see how that's handled here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the envVarsList already merge all env var from all files together. I think it would be easier to add the logic to handle repeated variable in the ReadEnvVarsFromEnvfiles when creating the envVarsList.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the original thought is that envVarsList is a list that follows the original order of what was entered in the task def, so if an env var already exists in the map, we don't add to it because whatever was entered into the map first has precedence (just based on the list order). however, i add to the list of downloaded paths with a go routine so i need to double check if that's still the case..
} | ||
// only read the line that has "=" | ||
if strings.Contains(line, envVariableDelimiter) { | ||
variables := strings.Split(line, "=") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this will read a line that has "=" anywhere, e.g. strings.Split("=xyz ", "=") returns ["", "xyz"]. Im inclined to use regex or any other validation that makes sure either side of = is at least length of one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we decided not to add any agent specific validations, so at least we should understand what happens when invalid line is passed to docker.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good point - and is the existing logic to ignore any lines that is a comment or doesn't match the regex ok?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
im ok with that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
instead of regex i added a super simple "if both sides length > 0" lmk if you have any concerns, i'm open to adding it as regex
agent/api/task/task.go
Outdated
for _, container := range task.Containers { | ||
envfileResource, err := envFiles.NewEnvironmentFileResource(config.Cluster, task.Arn, config.AWSRegion, config.DataDir, | ||
container.EnvironmentFiles, credentialsManager, task.ExecutionCredentialsID) | ||
if err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since each container has their own task resource, you may want to have container name or other container identifier in the error message so people can understand which one is causing the error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good point - also added check for containers having env files before creating a resource. instead of checking all containers and then checking again.
agent/engine/docker_task_engine.go
Outdated
@@ -1018,6 +1018,14 @@ func (engine *DockerTaskEngine) createContainer(task *apitask.Task, container *a | |||
} | |||
} | |||
|
|||
if container.ShouldCreateWithEnvFiles() { | |||
err := task.ReadEnvVarsFromEnvfiles(container) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel it would be better for the name to be MergeEnvVarsFromEnvFiles, it makes me confusing for a second that where you merge the env vars until I read the function logic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have requirements for the order between secrets and the env file, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think the requirement is just that all existing env vars (in this case secret as well) have precendence - though it's highly unlikely that someone will create a secret but then also store it as plaintext in s3..or is it 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also renamed the method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mostly nits except for the one regarding environmentFileResourceJSON
|
||
mockOS.EXPECT().RemoveAll(resourceDir).Return(errors.New("error response")) | ||
|
||
assert.Error(t, envfileResource.Cleanup()) | ||
} | ||
|
||
func TestReadEnvVarsFromEnvfiles(t *testing.T) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we change this test to read from multiple env files to verify the env vars with same key are overriden correctly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i can add an additional test for this use case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wait this is already tested in container_test.go
this method wouldn't actually override any envvars, but return everything in the file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can merge your pr once you resolve the comments I left.
Summary
this commit initializes the environment files resource when task starts up, and reads the environment variables from those files when containers are created
note: i am getting this PR out to get eyes on it, there are additional unit tests that still need to be added.
Implementation details
When task starts up -> containers are checked to have environment files. if so, envfile resource is created. after files are retrieved (done in previous PR), when containers are created, those retrieved files are read and those environment variables are merged into a container's existing environment variables.
Testing
New tests cover the changes: yes
make test
is successfulDescription for the changelog
create envfile task resource on task start up as needed
Licensing
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.