-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Labels:None
-
Not Needed
-
Iteration Porpoise, Iteration Quahog
Parts of the project YAML are relying on a bug in Evergreen's YAML parsing library with regards to how nested fields are merged when using aliases. For example, in this snippet of the YAML, the current YAML parser will interpret this as:
post: - command: s3.put params: # Merge the save-artifacts params with the in-line params. aws_key: ${aws_key} aws_secret: ${aws_secret} buckets: mciuploads permissions: public-read content_type: text/plain local_files_include_filter: - src/.deps/.npm/_logs/*.log remote_file: ${project}/${revision}_${revision_order_id}/${build_variant}/${task_name}
This is relying on the fact that the YAML parser does a deep nested merge of the keys for the params map between the save-artifacts alias and the in-line defined params. However, the YAML spec states that in this case, it's supposed to actually do a shallow merge, which would result in this interpretation:
post: - command: s3.put params: # None of the keys from save-artifacts params are merged here because params is already defined in-line. content_type: text/plain local_files_include_filter: - src/.deps/.npm/_logs/*.log remote_file: ${project}/${revision}_${revision_order_id}/${build_variant}/${task_name}
This bug has been fixed in the latest YAML parser version, and EVG-17291 will upgrade the YAML parser soon, so reliance on the deep nested merge behavior should be removed.