-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #1132 from awslabs/develop
v0.15.0 Release
- Loading branch information
Showing
47 changed files
with
865 additions
and
810 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,135 @@ | ||
SAM Build producing debuggable artifacts | ||
======================================== | ||
|
||
What is the problem? | ||
-------------------- | ||
|
||
`sam build` produces artifacts that are built for production use. In some langauges (usually interpreted), | ||
these production artifacts are also debuggable locally. In the case of compiled languages, you usually need to compile | ||
the binary or artifact in a specific manner for them to be debuggable. | ||
|
||
What will be changed? | ||
--------------------- | ||
|
||
We will introduce a way in `sam build` to produce these debuggable artifacts for those compiled languages. | ||
|
||
Success criteria for the change | ||
------------------------------- | ||
|
||
1. Artifacts generated will be debuggable for runtimes DotNetCore 2.0 and above. | ||
|
||
Out-of-Scope | ||
------------ | ||
|
||
1. Other languages `sam build` supports will not be changed | ||
|
||
User Experience Walkthrough | ||
--------------------------- | ||
|
||
Implementation | ||
============== | ||
|
||
CLI Changes | ||
----------- | ||
|
||
*Explain the changes to command line interface, including adding new | ||
commands, modifying arguments etc* | ||
|
||
### Breaking Change | ||
|
||
Changes are additive and will not break any existing functionality. | ||
|
||
Design | ||
------ | ||
|
||
Options considered | ||
------------------ | ||
We have a couple options to consider: | ||
|
||
1. A command line option (`--mode`) | ||
* Pros | ||
* Customer can control what kind of artifacts are produced. | ||
* There is no guessing needed by the CLI | ||
* Cons | ||
* Yet another option for customers to learn or know about | ||
* Makes the customer need to think about the artifacts they need to produce (though this can be hidden | ||
behind the AWS Toolkit in IDEs) | ||
* Customers running in the command line need to remember what artifacts to produce or what they previously produced | ||
2. An Environment Variable we read (`SAM_BUILD_MODE`). IDE Toolkit will set the env var when calling `sam build` | ||
while debugging. | ||
* Pros | ||
* Reduces cognitive load on customers that don't care about debugging dotnet apps through command line. | ||
* Could force customers to use AWS Toolkit by default | ||
* Cons | ||
* Building debug artifacts becomes a hidden feature (silent contract) | ||
* Environment Variables tend to be more set and forget. | ||
* Need to conditionally add Env Var instead of a more convenient flag | ||
3. Seamless Integration: `sam build` produces debug artifacts by default and `sam package` will build | ||
non debug artifacts by default | ||
* Pros | ||
* Customers should never have to think about 'when to produce debug artifacts' or forget to add a flag | ||
* Cons | ||
* Requires additional work on package to auto build. | ||
* Breaks what is produced from `sam build` as build is positioned to produce artifacts that are ready for deployment | ||
|
||
Proposal | ||
-------- | ||
|
||
My recommendation is to follow Option #2 from above, mainly because: | ||
|
||
- Seamless Integration (#3) is best experience but is large in scope. | ||
- CLI Option (#1) exposes a flag for what we think will be a rarely used CLI feature. We think so because manually | ||
setting up debugging is cumbersome. Given that .NET developers generally prefer to be within the IDE, I find it hard | ||
to believe someone will want to go out of the way of setting it up through CLI. | ||
- Not a one-way-door. We can always add a CLI option to pair with env var later. | ||
|
||
`.samrc` Changes | ||
---------------- | ||
|
||
*Explain the new configuration entries, if any, you want to add to | ||
.samrc* | ||
|
||
Security | ||
-------- | ||
|
||
*Tip: How does this change impact security? Answer the following | ||
questions to help answer this question better:* | ||
|
||
**What new dependencies (libraries/cli) does this change require?** | ||
No | ||
|
||
**What other Docker container images are you using?** | ||
N/A | ||
|
||
**Are you creating a new HTTP endpoint? If so explain how it will be | ||
created & used** | ||
No | ||
|
||
**Are you connecting to a remote API? If so explain how is this | ||
connection secured** | ||
No | ||
|
||
**Are you reading/writing to a temporary folder? If so, what is this | ||
used for and when do you clean up?** | ||
No | ||
|
||
**How do you validate new .samrc configuration?** | ||
N/A | ||
|
||
Documentation Changes | ||
--------------------- | ||
|
||
Open Issues | ||
----------- | ||
|
||
Task Breakdown | ||
-------------- | ||
|
||
- \[x\] Send a Pull Request with this design document | ||
- \[ \] Build the command line interface | ||
- \[ \] Build the underlying library | ||
- \[ \] Unit tests | ||
- \[ \] Functional Tests | ||
- \[ \] Integration tests | ||
- \[ \] Run all tests on Windows | ||
- \[ \] Update documentation |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2,4 +2,4 @@ | |
SAM CLI version | ||
""" | ||
|
||
__version__ = '0.14.2' | ||
__version__ = '0.15.0' |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.