Initial commit

Signed-off-by: Alessandro Pomponio <[email protected]>

Author: AlessandroPomponio

.github/dco.yml

@@ -0,0 +1,4 @@
+# This enables DCO bot for you, please take a look https://github.com/probot/dco
+# for more details.
+require:
+  members: false

.travis.yml

@@ -0,0 +1,42 @@
+language: bash
+
+stages:
+  - name: "Build test image"
+    if: tag is blank AND branch != main
+  - name: "Build production image"
+    if: branch = main AND type != pull_request AND tag is blank
+  - name: "Build platform image"
+    if: tag is present
+
+before_install:
+  # Install the buildx plugin
+  - mkdir -vp ~/.docker/cli-plugins/
+  - curl --silent -L "https://github.com/docker/buildx/releases/download/v0.9.1/buildx-v0.9.1.linux-amd64" > ~/.docker/cli-plugins/docker-buildx
+  - chmod a+x ~/.docker/cli-plugins/docker-buildx
+  # Enable experimental features
+  - export DOCKER_CLI_EXPERIMENTAL=enabled
+  - export DOCKER_BUILD_KIT=1
+  # Change buildx output style
+  - export BUILDKIT_PROGRESS=plain
+  - set -e
+
+jobs:
+  include:
+    - stage: "Build test image"
+      os: linux
+      services:
+        - docker
+      script:
+        - ./build_and_push.sh ${DOCKER_REGISTRY}/experimental/st4sd-registry-backend
+    - stage: "Build production image"
+      os: linux
+      services:
+        - docker
+      script:
+        - ./build_and_push.sh ${DOCKER_REGISTRY}/st4sd-registry-backend
+    - stage: "Build platform image"
+      os: linux
+      services:
+        - docker
+      script:
+        - ./build_and_push.sh ${DOCKER_REGISTRY}/st4sd-registry-backend:release-candidate

.whitesource

@@ -0,0 +1,3 @@
+{
+  "settingsInheritedFrom": "whitesource-config/whitesource-config@master"
+}

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](./MAINTAINERS.md). 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

@@ -0,0 +1,69 @@
+## Contributing In General
+Our project welcomes external contributions. If you have an itch, please feel
+free to scratch it.
+
+To contribute code or documentation, please submit a [pull request](https://github.com/st4sd/st4sd-registry-backend/pulls).
+
+A good way to familiarize yourself with the codebase and contribution process is
+to look for and tackle low-hanging fruit in the [issue tracker](https://github.com/st4sd/st4sd-registry-backend/issues).
+Before embarking on a more ambitious contribution, please quickly [get in touch](MAINTAINERS.md) with us.
+
+**Note: We appreciate your effort, and want to avoid a situation where a contribution
+requires extensive rework (by you or by us), sits in backlog for a long time, or
+cannot be accepted at all!**
+
+### Proposing new features
+
+If you would like to implement a new feature, please [raise an issue](https://github.com/st4sd/st4sd-registry-backend/issues)
+before sending a pull request so the feature can be discussed. This is to avoid
+you wasting your valuable time working on a feature that the project developers
+are not interested in accepting into the code base.
+
+### Fixing bugs
+
+If you would like to fix a bug, please [raise an issue](https://github.com/st4sd/st4sd-registry-backend/issues) before sending a
+pull request so it can be tracked.
+
+### Merge approval
+
+The project maintainers use LGTM (Looks Good To Me) in comments on the code
+review to indicate acceptance. A change requires LGTMs from two of the
+maintainers of each component affected.
+
+For a list of the maintainers, see the [MAINTAINERS.md](MAINTAINERS.md) page.
+
+## Legal
+
+Each source file must include a license header for the Apache
+Software License 2.0. Using the SPDX format is the simplest approach.
+e.g.
+
+```
+/*
+Copyright IBM Inc. All Rights Reserved.
+
+SPDX-License-Identifier: Apache-2.0
+*/
+```
+
+We have tried to make it as easy as possible to make contributions. This
+applies to how we handle the legal aspects of contribution. We use the
+same approach - the [Developer's Certificate of Origin 1.1 (DCO)](https://github.com/hyperledger/fabric/blob/master/docs/source/DCO1.1.txt) - that the Linux® Kernel [community](https://elinux.org/Developer_Certificate_Of_Origin)
+uses to manage code contributions.
+
+We simply ask that when submitting a patch for review, the developer
+must include a sign-off statement in the commit message.
+
+Here is an example Signed-off-by line, which indicates that the
+submitter accepts the DCO:
+
+```
+Signed-off-by: John Doe <[email protected]>
+```
+
+You can include this automatically when you commit a change to your
+local git repository using the following command:
+
+```
+git commit -s
+```

Dockerfile

@@ -0,0 +1,9 @@
+FROM quay.io/st4sd/official-base/st4sd-runtime-core
+COPY requirements.txt .
+COPY *.py ./
+COPY apis ./apis
+COPY utils ./utils
+RUN pip install -r requirements.txt
+EXPOSE 8085
+
+ENTRYPOINT ["python", "app.py"]