Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 37 additions & 0 deletions .github/instructions/s3.instructions.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
---
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done.

applyto: "sdk/src/Services/S3/**"
---


# Purpose

This document provides a comprehensive guideline for how to review S3 generation pull requests. S3 generation pull requests are pull requests which convert custom s3 code to generated s3 code. This means that the code is no longer written by hand and is generated by the generator located in `generator/ServiceClientGeneratorLib/**`. A generated file exists under the generated folder while a custom file exists under the custom folder. Here is an example of a file that has been moved from custom to generated:

* `sdk/src/Services/S3/Custom/Model/InitiateMultipartUploadRequest.cs` is the custom file
* `sdk/src/Services/S3/Generated/Model/InitiateMultipartUploadRequest.cs` is the generated file the code is moved to.

It isn't always possible to fully generate the s3 code so in some cases the logic will be split between a custom marshaller and a generated marshaller:

Here is an example of s3 marshaller logic split between two files:

* `sdk/src/Services/S3/Custom/Model/Internal/MarshallTransformations/GetObjectMetadataRequestMarshaller.cs`
* `sdk/src/Services/S3/Generated/Model/Internal/MarshallTransformations/GetObjectMetadataRequestMarshaller.cs`

In the example above, the logic that can't be generated has been moved to a custom partial method inside of the custom file called `PostMarshallCustomization`, which the generated marshaller then calls.

When a custom file is split between two files (custom and generated) the custom and generated should be looked as a whole when analyzing the logic.

The same can be said about unmarshallers. Here is an example of S3 unmarshaller logic that is split between two files:
* `sdk/src/Services/S3/Generated/Model/Internal/MarshallTransformations/ListObjectsV2ResponseUnmarshaller.cs`
* `sdk/src/Services/S3/Custom/Model/Internal/MarshallTransformations/ListObjectsV2ResponseUnmarshaller.cs`

In the example above, the logic that can't be generated has been moved to a custom method called `CustomContentsUnmarshall` that is called from within the generated unmarshaller. The name of the custom method will differ depending on what the custom method is doing, but the pattern of the generated unmarshaller calling a custom method will be commonly found within S3 generation pull requests.

Similarly to the s3 marshallers, when the custom file is split between two files (custom and generated) the custom and generated should be looked as a whole when analyzing the logic.

# Guidelines for reviewing S3 Generation Pull Requests
Your job is to ensure there are no breaking changes when comparing the custom code to the generated code (or a combination of custom + generated code). Some things that would cause breaking changes are:
1. logical conditions that existed in the older code have been changed or removed.
2. getter and setter code have changed, disregarding private variable name changes such as _type and type.
3. properties that were set to values that are no longer set.
4. changes in the response output.