You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thank you for your interest in contributing to our project. Whether it's a bug report, new feature, correction, or additional
4
+
documentation, we greatly value feedback and contributions from our community.
5
+
6
+
Please read through this document before submitting any issues or pull requests to ensure we have all the necessary
7
+
information to effectively respond to your bug report or contribution.
8
+
9
+
10
+
## Reporting Bugs/Feature Requests
11
+
12
+
We welcome you to use the GitHub issue tracker to report bugs or suggest features.
13
+
14
+
When filing an issue, please check existing open, or recently closed, issues to make sure somebody else hasn't already
15
+
reported the issue. Please try to include as much information as you can. Details like these are incredibly useful:
16
+
17
+
* A reproducible test case or series of steps
18
+
* The version of our code being used
19
+
* Any modifications you've made relevant to the bug
20
+
* Anything unusual about your environment or deployment
21
+
22
+
23
+
## Contributing via Pull Requests
24
+
Contributions via pull requests are much appreciated. Before sending us a pull request, please ensure that:
25
+
26
+
1. You are working against the latest source on the *main* branch.
27
+
2. You check existing open, and recently merged, pull requests to make sure someone else hasn't addressed the problem already.
28
+
3. You open an issue to discuss any significant work - we would hate for your time to be wasted.
29
+
30
+
To send us a pull request, please:
31
+
32
+
1. Fork the repository.
33
+
2. Modify the source; please focus on the specific change you are contributing. If you also reformat all the code, it will be hard for us to focus on your change.
34
+
3. Ensure local tests pass.
35
+
4. Commit to your fork using clear commit messages.
36
+
5. Send us a pull request, answering any default questions in the pull request interface.
37
+
6. Pay attention to any automated CI failures reported in the pull request, and stay involved in the conversation.
38
+
39
+
GitHub provides additional document on [forking a repository](https://help.github.com/articles/fork-a-repo/) and
40
+
[creating a pull request](https://help.github.com/articles/creating-a-pull-request/).
41
+
42
+
43
+
## Finding contributions to work on
44
+
Looking at the existing issues is a great way to find something to contribute on. As our projects, by default, use the default GitHub issue labels (enhancement/bug/duplicate/help wanted/invalid/question/wontfix), looking at any 'help wanted' issues is a great place to start.
45
+
46
+
47
+
## Code of Conduct
48
+
This project has adopted the [Amazon Open Source Code of Conduct](https://aws.github.io/code-of-conduct).
49
+
For more information see the [Code of Conduct FAQ](https://aws.github.io/code-of-conduct-faq) or contact
50
+
opensource-codeofconduct@amazon.com with any additional questions or comments.
51
+
52
+
53
+
## Security issue notifications
54
+
If you discover a potential security issue in this project we ask that you notify AWS/Amazon Security via our [vulnerability reporting page](http://aws.amazon.com/security/vulnerability-reporting/). Please do **not** create a public github issue.
55
+
56
+
57
+
## Licensing
58
+
59
+
See the [LICENSE](LICENSE) file for our project's licensing. We will ask you to confirm the licensing of your contribution.
Copy file name to clipboardExpand all lines: README.md
+7-51Lines changed: 7 additions & 51 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,12 +6,11 @@ by Tim McNamara ([@timClicks](https://github.com/timClicks)).
6
6
7
7
## Directory layout
8
8
9
-
10
9
-`examples`: examples of code that is discussed within the talks slides
11
10
-`serverless-compare-langs`: 5 implementations of an ecommerce application, one per language
12
11
13
12
14
-
## `serverless-compare-langs`
13
+
###`serverless-compare-langs`
15
14
16
15
The code within these directories is sourced from AWS repositories via the `sit subtree` command:
17
16
@@ -25,62 +24,19 @@ The code within these directories is sourced from AWS repositories via the `sit
25
24
26
25
The upstream repositories have had slight customizations to enable them to be deployed concurrently.
27
26
28
-
<!--
29
-
## Getting started
30
-
31
-
To make it easy for you to get started with GitLab, here's a list of recommended next steps.
32
-
33
-
Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!
34
-
35
-
## Add your files
36
-
37
-
- [ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files
38
-
- [ ] [Add files using the command line](https://docs.gitlab.com/ee/gitlab-basics/add-file.html#add-a-file-using-the-command-line) or push an existing Git repository with the following command:
- [ ] [Set up project integrations](https://gitlab.aws.dev/timmcn/build-on-aws-with-rust/-/settings/integrations)
27
+
## Security
50
28
51
-
## Collaborate with your team
29
+
See [CONTRIBUTING](CONTRIBUTING.md#security-issue-notifications) for more information.
52
30
53
-
- [ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/)
54
-
- [ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
55
-
- [ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
- [ ] [Automatically merge when pipeline succeeds](https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html)
58
-
59
-
## Test and Deploy
60
-
61
-
Use the built-in continuous integration in GitLab.
62
-
63
-
- [ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/index.html)
64
-
- [ ] [Analyze your code for known vulnerabilities with Static Application Security Testing(SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
65
-
- [ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
66
-
- [ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
67
-
- [ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)
68
-
69
-
***
31
+
## License
70
32
71
-
# Editing this README
33
+
This library is licensed under the MIT-0 License. See the LICENSE file.
72
34
73
-
When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thank you to [makeareadme.com](https://www.makeareadme.com/) for this template.
35
+
<!--
74
36
75
37
## Suggestions for a good README
76
38
Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information.
77
39
78
-
## Name
79
-
Choose a self-explaining name for your project.
80
-
81
-
## Description
82
-
Let people know what your project can do specifically. Provide context and add a link to any reference visitors might be unfamiliar with. A list of Features or a Background subsection can also be added here. If there are alternatives to your project, this is a good place to list differentiating factors.
83
-
84
40
## Badges
85
41
On some READMEs, you may see small images that convey metadata, such as whether or not all the tests are passing for the project. You can use Shields to add some to your README. Many services also have instructions for adding a badge.
86
42
@@ -115,4 +71,4 @@ For open source projects, say how it is licensed.
115
71
## Project status
116
72
If you have run out of energy or time for your project, put a note at the top of the README saying that development has slowed down or stopped completely. Someone may choose to fork your project or volunteer to step in as a maintainer or owner, allowing your project to keep going. You can also make an explicit request for maintainers.
0 commit comments