Merge branch 'master' into master

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,10 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**We do not triage issue for this repo. All issues are triaged in sonic-net/sonic-buildimage repo**

.github/workflows/sonic_image_links_create_workflow.yml

@@ -0,0 +1,21 @@
+# This is a basic workflow to help you get started with GitHub Actions
+
+name: Run the shell script to generate sonic image links in sonic_image_links.json in a dedicated branch
+
+# Run the script once in a minute. Github may take 15 minutes to run this even though we request once in a minute, which is OK.
+on:
+  schedule:
+    - cron:  '* * * * *'
+
+jobs:
+  build:
+    # The type of runner that the job will run on
+    runs-on: ubuntu-latest
+
+    # Steps represent a sequence of tasks that will be executed as part of the job
+    steps:
+      - uses: actions/checkout@v2 
+
+      - name: Run the script to build a json file with details about various builds for various platforms
+        run: sh ./generate_sonic_image_links.sh
+

.github/workflows/supported_devices_platforms_md.yml

@@ -0,0 +1,20 @@
+# This is a basic workflow to help you get started with GitHub Actions
+
+name: Run the shell script to generate sonic image links in supported_devices_platforms_md.sh in a dedicated branch
+
+# Run the script once in a minute. Github may take 15 minutes to run this even though we request once in a minute, which is OK.
+on:
+  schedule:
+    - cron:  '5 * * * *'
+
+jobs:
+  build:
+    # The type of runner that the job will run on
+    runs-on: ubuntu-latest
+
+    # Steps represent a sequence of tasks that will be executed as part of the job
+    steps:
+      - uses: actions/checkout@v2 
+
+      - name: Run the script to build a json file with details about various builds for various platforms
+        run: sh ./supported_devices_platforms_md.sh

.gitignore

@@ -0,0 +1,5 @@
+*~
+*.swp
+*.un~
+.DS_Store
+.vscode/

CODE_OF_CONDUCT.md

@@ -0,0 +1,76 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+ advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+ address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+ professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at sonic-codeofconduct@googlegroups.com. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq

CONTRIBUTING.md

@@ -33,21 +33,21 @@ For example:
 * Use a pull request to do code review
 * Use issues to keep track of what is going on
 
-##Expectations for pull requests
-Pull requests should be free of any known bugs and be accompanied by tests and appropriate documentation.  Test coverage may include unit tests, integration tests such as [PTF tests](https://github.com/Azure/SONiC/wiki/HOWTO-write-a-PTF-Test) defined in the [sonic-mgmt repo](https://github.com/Azure/sonic-mgmt/tree/master/ansible/roles/test/tasks).
+## Expectations for pull requests
+Pull requests should be free of any known bugs and be accompanied by tests and appropriate documentation.  Test coverage may include unit tests, integration tests such as [PTF tests](https://github.com/sonic-net/SONiC/wiki/HOWTO-write-a-PTF-Test) defined in the [sonic-mgmt repo](https://github.com/sonic-net/sonic-mgmt/tree/master/ansible/roles/test/tasks).
 
 ## Commiting new test
-When commiting a new feature with a new test, please complete a [test plan from the template](doc/SONiC%20Test%20Plan%20Template.md)
+When committing a new feature with a new test, please complete a [test plan from the template](doc/SONiC%20Test%20Plan%20Template.md)
 
 
-##Responding to pull requests
+## Responding to pull requests
 Responsible individual: A contribution needs to be looked at by its 
 maintainers. In the absence of the maintainer, the project leader can respond.
 A pull request should be responded to in approximately 48 hours. This does 
 not mean the contribution will be resolved in 48 hours.  It could even mean 
 an email that states: “busy now, will get to it soon.” 
 
-##Contributors License Agreement
-All contributors must sign a contribution license agreement before 
-contributions can be accepted.  Send email to [sonic-cla](mailto:sonic-cla-agreements@microsoft.com)
-to request a copy of the contributors a license agreement to be signed.
+## Contributors License Agreement
+All contributors must sign an [Individual Contributor License Agreement (ICLA)](https://docs.linuxfoundation.org/lfx/easycla/v2-current/contributors/individual-contributor) before 
+contributions can be accepted. This process is managed by the [Linux Foundation - EasyCLA](https://easycla.lfx.linuxfoundation.org/) and automated
+via a GitHub bot. If the contributor has not yet signed a CLA, the bot will create a comment on the pull request containing a link to electronically sign the CLA.