Initial commit

.github/ISSUE_TEMPLATE/bug-report.md

@@ -0,0 +1,32 @@
+---
+name: Bug report
+about: Report a bug in the project
+---
+
+<!-- Thank you for your contribution. Before you submit the issue:
+1. Search open and closed issues for duplicates.
+2. Read the contributing guidelines.
+-->
+
+**Description**
+
+<!-- Provide a clear and concise description of the problem.
+Describe where it appears, when it occurred, and what it affects.  -->
+
+<!-- Provide relevant technical details such as the browser name and version, or the operating system. -->
+
+**Expected result**
+
+<!-- Describe what you expect to happen. -->
+
+**Actual result**
+
+<!-- Describe what happens instead. -->
+
+**Steps to reproduce**
+
+<!-- List the steps to follow to reproduce the bug. Attach any files, links, code samples, or screenshots that could help in investigating the problem. -->
+
+**Troubleshooting**
+
+<!-- Describe the steps you have already taken to solve the issue. -->

.github/ISSUE_TEMPLATE/decision-record.md

@@ -0,0 +1,35 @@
+---
+name: Decision record
+about: Decision record
+---
+<!-- Follow the decision making process (https://kyma-project.io/community/governance) -->
+
+Created on {YYYY-MM-DD} by {name and surname (@Github username)}.
+
+## Decision log
+
+| Name | Description |
+|-----------------------|------------------------------------------------------------------------------------|
+| Title | {Provide a brief summary of the decision.} |
+| Due date | {Specify the date by which the SIG or WG members need to make the decision. Use the `YYYY-MM-DD` date format.} |
+| Status | {The status of the document can be `Accepted`, `Declined`, or `Proposed` when it is waiting for a decision. This section should contain one of these three words followed by the date on which the status of the document is agreed on. Follow the `YYYY-MM-DD` format for the date. For example, write `Proposed on 2018-03-20` or `Accepted on 2018-03-23`. Add the new status when it changes. Do not overwrite previous status entries.}|
+| Decision type | {Type in `Binary`, `Choice`, or `Prioritization`. The `Binary` type refers to the  yes/no decisions, the `Choice` type means that the decision involves choosing between many possibilities, such as a name for a new product, and the `Prioritization` type involves ranking a number of options, such as choosing the next five features to build out of one hundred possible options.} |
+| Affected decisions | {Specify the ID of the decision issue or a link to the previous decision record which is affected by this decision. Use the `#{issueid}\|{decision-record-URL}(replaces\|extends\|depends on)` format. For example, write `#265(replaces)` or `#278(depends on)` which means that the decision you propose replaces the issue 265 or depends on the issue 278. Specify as many references as possible and separate them with a comma. Write `None` if no other decision is affected.}|
+
+## Context
+
+<!-- Briefly describe what the decision record (DR) is about.
+Explain the factors for the decision, what are the forces at play, and the reasons why the discussed solution is needed.
+Remember that this document should be relatively short and concise. If necessary, provide relevant links for more details.
+If the decision concerns more solutions, mark them with separate subsections. Use H3 for the subsection headings.  -->
+
+## Decision
+
+<!--Avoid using personal constructions such as "we." Use impersonal forms instead.
+For example, `The decision is to...`. If it is necessary to indicate the subject, use `SIG/WG members` instead of "we." -->
+
+## Consequences
+
+<!-- Briefly explain the consequences of this decision for the Kyma project.
+Include both the advantages and disadvantages of the discussed solution.
+-->

.github/ISSUE_TEMPLATE/documentation-improvement.md

@@ -0,0 +1,34 @@
+---
+name: Documentation improvement
+about: Suggest an improvement or report a bug in the documentation
+---
+
+<!-- Thank you for your contribution. Before you submit the issue:
+1. Search open and closed issues for duplicates.
+2. Read the contributing guidelines.
+3. Assign the Documentation project.
+-->
+
+**Description**
+
+<!-- Provide a clear and concise description of the potential documentation improvement.-->
+
+**Area**
+
+<!-- Provide the area the document refers to. For example, write: 
+* Application Connector
+* Event Mesh
+* Kyma Environment Broker
+* Rafter -->
+
+**Reasons**
+
+<!-- Explain why we should improve the document. -->
+
+**Assignees**
+
+@kyma-project/technical-writers
+
+**Attachments**
+
+<!-- Attach any files, links, code samples, or screenshots that will convince us to your idea. -->

.github/ISSUE_TEMPLATE/feature-request.md

@@ -0,0 +1,21 @@
+---
+name: Feature request
+about: Suggest an improvement to the project
+---
+
+<!-- Thank you for your contribution. Before you submit the issue:
+1. Search open and closed issues for duplicates.
+2. Read the contributing guidelines.
+-->
+
+**Description**
+
+<!-- Provide a clear and concise description of the feature. -->
+
+**Reasons**
+
+<!-- Explain why we should add this feature. Provide use cases to illustrate its benefits. -->
+
+**Attachments**
+
+<!-- Attach any files, links, code samples, or screenshots that will convince us to your idea. -->

.github/ISSUE_TEMPLATE/new-sig-or-wg-proposal.md

@@ -0,0 +1,80 @@
+---
+name: SIG or WG proposal
+about: Propose a new SIG or WG
+---
+
+<!-- Thank you for your contribution. Before you submit the issue:
+1. Search other groups for relevance of your topics.
+2. Read the governance model (https://kyma-project.io/community/governance).
+3. Collect at least five candidates for this group.
+-->
+
+**Proposal type**
+<!-- Remove the type that does not fit. -->
+* Special Interest Group (SIG)
+* Working Group (WG)
+
+**Name**
+* Full name of the group:
+<!-- Specify the abbreviated name for slack channels, issue labels, and pull request labels.
+The abbreviate name must be no longer than six characters. -->
+* Abbreviated name:
+
+**Earliest start date**
+<!-- Specify the earliest date for this group to start their work. This is required to make a timely decision on the group creation. -->
+* {YYYY-MM-DD}
+
+**Visibility**
+<!-- Remove the type that does not fit. -->
+* Internal
+* Public
+
+**Keywords** (optional)
+<!-- List several keywords or labels that relate to the working domain of this group. -->
+* ...
+* ...
+* ...
+
+**Proposers**
+<!-- List the names and the GitHub usernames of people who are authors of this proposal. -->
+* ...
+* ...
+* ...
+
+**Purpose and goals**
+<!-- Describe the purpose and the goals of this group.  -->
+
+**Benefits**
+<!-- Provide the reasons for organizing this group. Describe how the Kyma project or the Kyma community can benefit from the work of this group. -->
+
+**Expected results**
+<!-- Describe what you expect as deliverables of this group and how they relate to the purpose and the goals of this group. Provide a provisionary timeline or phases if possible. -->
+
+**Expected membership and governance**
+<!-- Provide the details even if they are not final yet. -->
+* Meeting frequency: <!-- Define if the group meets daily, weekly, bi-weekly, or monthly. -->
+* Membership: <!-- Provide the approximate number of initial members. -->
+* Duration: <!-- This field is mandatory for a WG. -->
+
+**Previous approach** (optional)
+<!-- Describe if and how these topics were previously addressed and why you think this group can improve them.-->
+
+**Measures of success** (optional for SIG)
+<!-- List the criteria to assess if the group's work is successful and adds value.
+Describe the methods of performing and documenting the regular self-assessment by the group. -->
+* ...
+* ...
+* ...
+
+**Assessment frequency**
+<!-- Define how often the group evaluates its work. Remove the type that does not fit. -->
+* Monthly
+* Quarterly
+* Biannually
+* Annually
+
+**Exit criteria**
+<!-- List the conditions and risks that can lead to dissolving the group. Be specific and do not make general statements. -->
+* ...
+* ...
+* ...

.github/ISSUE_TEMPLATE/security-vulnerability.md

@@ -0,0 +1,57 @@
+---
+name: Security vulnerability
+about: Report vulnerability in the project
+---
+
+<!-- Thank you for your contribution. Before you submit the issue:
+1. Search open and closed issues for duplicates.
+2. Read the contributing guidelines.
+3. In case of vulnerabilities of CVSS Base Score *7.0* or above, send an email directly to [email protected] instead of using this issue tracker. You can also use email for vulnerabilities with lower severity if you prefer to keep your report confidential.
+-->
+
+**Description**
+
+<!-- Provide a clear and concise description of the vulnerability.
+Describe where it appears, when it occurred, and what it affects.  -->
+
+<!-- Provide relevant technical details such as the browser name and version, or the operating system. -->
+
+**Steps to exploit**
+
+<!-- List the steps an attacker would follow to exploit the vulnerability. Attach any files, links, code samples, or screenshots that could help in reproducing the attack. -->
+
+**Risk assessment**
+
+<!-- Propose a CVSSv3.0 Base Score for the vulnerability.
+Please use the CVSS calculator at https://www.first.org/cvss/calculator/3.0 and fill in the risk metrics for the CVSS Base Score. Then replace the placeholders in the following template: -->
+[{CVSS Vector String}]({CVSS Calculator URL}) **{CVSS Base Score} ({CVSS Base Severity})**
+<!--
+For example:
+[CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N) **7.1 (High)**
+
+Placeholder details:
+* {CVSS Vector String}:
+  Vector String representation of the CVSS metrics, as displayed by the CVSS calculator.
+  For example: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N
+* {CVSS Calculator URL}:
+  A deeplink to the CVSS calculator with the metrics that you propose.
+  Automatically appears in your browser's URL bar after you filled in the metrics.
+  Contains the {CVSS Vector String}.
+  For example: https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N
+* {CVSS Base Score}:
+  The numeric risk score determined by the CVSS calculator.
+  Appears prominently in the upper right corner of the base score area. Ranges from 0 to 10.
+  For example: 7.1
+* {CVSS Base Severity}:
+  A textual classification of the {CVSS Base Score}.
+  Appears right underneath the {CVSS Base Score} in the calculator.
+  Possible values are "None", "Low", "Medium", "High", and "Critical".
+  For example: High
+-->
+
+<!-- Feel free to leave a brief note here that explains the chosen CVSS metrics.-->
+
+
+**Proposed mitigation**
+
+<!-- Optionally, add any suggestions on how you would like to see this vulnerability mitigated. -->

.github/issue-template.md

@@ -0,0 +1,8 @@
+<!-- Thank you for your contribution. Before you submit the issue:
+1. Search open and closed issues for duplicates.
+2. Read the contributing guidelines.
+-->
+
+**Description**
+
+<!-- Provide a clear and concise description of the issue. -->

.github/pull-request-template.md

@@ -0,0 +1,19 @@
+<!--   Thank you for your contribution. Before you submit the pull request:
+1. Follow contributing guidelines, templates, the recommended Git workflow, and any related documentation.
+2. Read and submit the required Contributor Licence Agreements (https://github.com/kyma-project/community/blob/main/CONTRIBUTING.md#agreements-and-licenses).
+3. Test your changes and attach their results to the pull request.
+4. Update the relevant documentation.
+
+If the pull request requires a decision, follow the [decision-making process](https://github.com/kyma-project/community/blob/main/governance.md) and replace the PR template with the [decision record template](https://github.com/kyma-project/community/blob/main/.github/ISSUE_TEMPLATE/decision-record.md).
+-->
+
+**Description**
+
+Changes proposed in this pull request:
+
+- ...
+- ...
+- ...
+
+**Related issue(s)**
+<!-- If you refer to a particular issue, provide its number. For example, `Resolves #123`, `Fixes #43`, or `See also #33`. -->

.github/workflows/lint-markdown-links.yml

@@ -0,0 +1,14 @@
+name: Lint Markdown Links
+run-name: ${{github.event.pull_request.title}}
+on: [ pull_request ]
+jobs:
+  markdown-link-check:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - uses: gaurav-nelson/github-action-markdown-link-check@v1
+        with:
+          use-verbose-mode: 'no'
+          config-file: '.mlc.config.json'
+          folder-path: '.'
+          max-depth: -1

.github/workflows/pull-gitleaks.yml

@@ -0,0 +1,23 @@
+name: pull-gitleaks
+on:
+  pull_request:
+    types: [opened, edited, synchronize, reopened, ready_for_review]
+
+env:
+  GITLEAKS_VERSION: 8.18.2
+
+jobs:
+  scan:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      - name: Fetch gitleaks ${{ env.GITLEAKS_VERSION }}
+        run: curl -Lso gitleaks.tar.gz https://github.com/gitleaks/gitleaks/releases/download/v${{ env.GITLEAKS_VERSION }}/gitleaks_${{ env.GITLEAKS_VERSION }}_linux_x64.tar.gz && tar -xvzf ./gitleaks.tar.gz
+      - name: Run gitleaks
+        # Scan commits between base and head of the pull request
+        run: ./gitleaks detect --log-opts=${PULL_BASE_SHA}...${PULL_HEAD_SHA} --verbose --redact
+        env: 
+          PULL_BASE_SHA: ${{ github.event.pull_request.base.sha }}
+          PULL_HEAD_SHA: ${{ github.event.pull_request.head.sha }}

.github/workflows/stale.yml

@@ -0,0 +1,31 @@
+name: 'Manage Stale Issues and Pull Requests'
+
+on:
+  schedule:
+    - cron: '0 0 * * *'  # Runs daily at midnight
+  workflow_dispatch: # Allows manual triggering of the workflow
+
+jobs:
+  stale:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/stale@v9
+        with:
+          days-before-stale: 60
+          days-before-close: 7
+          stale-issue-label: 'lifecycle/stale'
+          stale-pr-label: 'lifecycle/stale'
+          exempt-issue-labels: 'lifecycle/frozen,lifecycle/active'
+          exempt-pr-labels: 'lifecycle/frozen,lifecycle/active'
+          stale-issue-message: |
+            This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs.
+            Thank you for your contributions.
+          stale-pr-message: |
+            This pull request has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs.
+            Thank you for your contributions.
+          close-issue-message: |
+            This issue has been automatically closed due to the lack of recent activity.
+            /lifecycle rotten
+          close-pr-message: |
+            This pull request has been automatically closed due to the lack of recent activity.
+            /lifecycle rotten

.mlc.config.json

@@ -0,0 +1,14 @@
+{
+  "_comment": "This is a configuration file for the [Markdown link check](https://github.com/tcort/markdown-link-check).",
+  "_comment": "All `/kyma-project` repositories in GitHub use [Markdown link check](https://github.com/tcort/markdown-link-check) to check their Markdown files for broken links.",
+  "_comment": "Configuration and maintenance of the Markdown link check tool is the responsibility of a repository owner.",
+  "_comment": "See the following configuration example.",
+  "_comment": "For more details read the [repository guidelines](https://github.com/kyma-project/community/blob/main/docs/guidelines/repository-guidelines/01-new-repository-settings.md).",
+  "replacementPatterns": [
+    {
+      "_comment": "a replacement rule for all the in-repository references",
+      "pattern": "^/",
+      "replacement": "{{BASEURL}}/"
+    }
+  ]
+}