遵循以下最佳实践的项目将能够自愿的自我认证,并显示他们已经实现了核心基础设施计划(OpenSSF)徽章。 显示详细资料
[](https://www.bestpractices.dev/projects/1774)
<a href="https://www.bestpractices.dev/projects/1774"><img src="https://www.bestpractices.dev/projects/1774/badge"></a>
ONAP TOSCA parser and ETSI catalog tools, the generic parser is provided since Dublin release.
https://wiki.onap.org/display/DW/Developing+ONAP https://wiki.onap.org/display/DW/Developer+Best+Practices
ONAP requires both a Developer Certificate of Origin (DCO), and a Contributor License Agreement (CLA). https://wiki.onap.org/display/DW/Contribution+Agreements
The project governance is described at https://wiki.onap.org/display/DW/Community+Offices+and+Governance Further information can be found at https://wiki.onap.org/display/DW/ONAP+Technical+Community+Document
ONAP adheres to the Linux Foundation Code of Conduct, found at https://lfprojects.org/policies/code-of-conduct/
The key roles in the project and their responsibilities are described at https://wiki.onap.org/display/DW/Community+Offices+and+Governance Current members are listed at https://wiki.onap.org/pages/viewpage.action?pageId=8226539
The committers are listed in the INFO.yaml: https://gerrit.onap.org/r/gitweb?p=modeling/etsicatalog.git;a=blob;f=INFO.yaml;h=bb2b662bfa0a85fe192269f954c1bdf1fd640a5f;hb=HEAD
Modeling release planning wiki page: https://wiki.onap.org/display/DW/Modeling+Release+Planning
The architecture is documented here: https://wiki.onap.org/display/DW/Etsicatalog+Architecture https://wiki.onap.org/pages/viewpage.action?pageId=93005531
A security sub-committee is driving all components release requirements, best practices. Agreed recommendations become integral parts of an ONAP release and are assessed during milestones. URL : https://wiki.onap.org/display/DW/ONAP+Security+coordination The release note clearly states what has been achieved, along with the release checklists and links to individual JIRA items that covers the above security requirements.
Information on setting up ONAP can be found at: https://docs.onap.org/en/latest/guides/onap-operator/settingup/index.html Information for Modeling can be found at: https://docs.onap.org/projects/onap-modeling-etsicatalog/en/latest/developer-guide.html
Every release has a branch for documentation, such as: https://gerrit.onap.org/r/gitweb?p=vfc/nfvo/lcm.git;a=tree;f=docs;h=135a293809bacdcfe47c9c4863d7ce2cc0e495d5;hb=HEAD
Our project page has the link embedded: https://wiki.onap.org/display/DW/Modeling+Project
Overall ONAP adherence to this is probably going to be handled ONAP wide
i18n is probably going to be handled ONAP wide
The project does not store password in the website, repository or downloads.
All major releases are tagged in gerrit and the artifacts are stored with the release information on onap.nexus. So we can access all old versions of the artifact. If and when a upgrade requires certain steps to be followed they are being added to the release documents as needed
Jira is used to track issues. https://wiki.onap.org/display/DW/Tracking+Issues+with+JIRA
Vulnerabilities can be reported using the link https://wiki.onap.org/pages/viewpage.action?pageId=6591711 Currently we dont have any vulnerabilities reported, but the wiki page explains on how to report a vulnerability and how to report anonymously if you do not want the credit for it.
Vulnerabilities handling is documented in https://wiki.onap.org/pages/viewpage.action?pageId=6591711
Coding style is defined in https://wiki.onap.org/display/DW/Java+code+style pylint for python components
Modeling project utilizes the ONAP checkstyle using the Maven maven-checkstyle-plugin for java project and pylint for python components
There is no native binaries
The application does not create native binaries.
Maven ensure submodules are built in the proper order. There are no bi-directional cross-dependencies between submodules.
All releases are tagged in gerrit(git), and the builds are controlled using jenkins. By providing the git tag information the same image can be build over and over again with same bit-for-bit result.
helm deploy onap helm undeploy onap
helm has no optional destination directories, but does let you direct pods to particular worker nodes
You can install the project by helm. The steps are documented in https://onap.readthedocs.io/en/latest/submodules/oom.git/docs/oom_quickstart_guide.html
The external dependencies are listed in: https://gerrit.onap.org/r/gitweb?p=modeling/etsicatalog.git;a=blob;f=requirements.txt;h=addba81e33969e0f2af5dce2ed2031a0cb6053cd;hb=HEAD
NexusIQ sonar scan is run on all the projects on a weekly basis
You can update the dependencies in requirements.txt when need at any time
We avoid depending on deprecated/obsolete functions. Sonar scans, which are run daily, identify the use of deprecated functions.
Automatic test suites are run every time before merging the code. The code check in cannot pass with out jenkins posting a +1 on the review.
When regressions occur, we add tests for them.
We use sonar to measure the overall code/branch coverage.
Contributing guide lines for development is recorded in https://wiki.onap.org/display/DW/Development+Procedures+and+Policies
This is documented on our wiki on Code Coverage and Static Code Analysis: https://wiki.onap.org/display/DW/Code+Coverage+and+Static+Code+Analysis and https://wiki.onap.org/display/DW/Creating+a+CSIT+Test
Build systems run the compile with test flag enabled by default. So any failure in test cases will fail the ci and the merge request.
in case of exception or any other issue during login for the REST APIs, the request is denied.
restful API is not based on HTTPS
ONAP integration team handle it together
we don't have whitelist
we don't have those mechanism yet in our HTTP headers
https://wiki.onap.org/display/DW/ONAP+Threat+Model
Sonar uses different rules for static code analysis.
Modeling use Python
后退