T6357: create test repository to validate setup

13 files changed, 383 insertions, 0 deletions

diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
new file mode 100644
index 0000000..cd348ea
--- /dev/null
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -0,0 +1,60 @@
+<!-- All PR should follow this template to allow a clean and transparent review -->
+<!-- Text placed between these delimiters is considered a comment and is not rendered -->
+
+## Change Summary
+<!--- Provide a general summary of your changes in the Title above -->
+
+## Types of changes
+<!---
+What types of changes does your code introduce? Put an 'x' in all the boxes that apply.
+NOTE: Markdown requires no leading or trailing whitespace inside the [ ] for checking
+the box, please use [x]
+-->
+- [ ] Bug fix (non-breaking change which fixes an issue)
+- [ ] New feature (non-breaking change which adds functionality)
+- [ ] Code style update (formatting, renaming)
+- [ ] Refactoring (no functional changes)
+- [ ] Migration from an old Vyatta component to vyos-1x, please link to related PR inside obsoleted component
+- [ ] Other (please describe):
+
+## Related Task(s)
+<!-- optional: Link to related other tasks on Phabricator. -->
+<!-- * https://vyos.dev/Txxxx -->
+
+## Related PR(s)
+<!-- Link here any PRs in other repositories that are required by this PR -->
+
+## Component(s) name
+<!-- A rather incomplete list of components: ethernet, wireguard, bgp, mpls, ldp, l2tp, dhcp ... -->
+
+## Proposed changes
+<!--- Describe your changes in detail -->
+
+## How to test
+<!---
+Please describe in detail how you tested your changes. Include details of your testing
+environment, and the tests you ran. When pasting configs, logs, shell output, backtraces,
+and other large chunks of text, surround this text with triple backtics
+```
+like this
+```
+-->
+
+## Smoketest result
+<!-- Provide the output of the smoketest
+```
+$ /usr/libexec/vyos/tests/smoke/cli/test_xxx_feature.py
+test_01_simple_options (__main__.TestFeature.test_01_simple_options) ... ok
+```
+-->
+
+## Checklist:
+<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
+<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
+<!--- The entire development process is outlined here: https://docs.vyos.io/en/latest/contributing/development.html -->
+- [ ] I have read the [**CONTRIBUTING**](https://github.com/vyos/vyos-1x/blob/current/CONTRIBUTING.md) document
+- [ ] I have linked this PR to one or more Phabricator Task(s)
+- [ ] I have run the components [**SMOKETESTS**](https://github.com/vyos/vyos-1x/tree/current/smoketest/scripts/cli) if applicable
+- [ ] My commit headlines contain a valid Task id
+- [ ] My change requires a change to the documentation
+- [ ] I have updated the documentation accordingly
diff --git a/.github/labeler.yml b/.github/labeler.yml
new file mode 100644
index 0000000..e0b9ee4
--- /dev/null
+++ b/.github/labeler.yml
@@ -0,0 +1,12 @@
+equuleus:
+  - any:
+    - base-branch: 'equuleus'
+current:
+  - any:
+    - base-branch: 'current'
+crux:
+  - any:
+    - base-branch: 'crux'
+sagitta:
+  - any:
+    - base-branch: 'sagitta'
diff --git a/.github/workflows/add-pr-labels.yml b/.github/workflows/add-pr-labels.yml
new file mode 100644
index 0000000..1723cce
--- /dev/null
+++ b/.github/workflows/add-pr-labels.yml
@@ -0,0 +1,19 @@
+---
+name: Add pull request labels
+
+on:
+  pull_request_target:
+    branches:
+      - current
+      - crux
+      - equuleus
+      - sagitta
+
+permissions:
+  pull-requests: write
+  contents: read
+
+jobs:
+  add-pr-label:
+    uses: vyos/.github/.github/workflows/add-pr-labels.yml@feature/T6349-reusable-workflows
+    secrets: inherit
diff --git a/.github/workflows/auto-author-assign.yml b/.github/workflows/auto-author-assign.yml
new file mode 100644
index 0000000..c3696ea
--- /dev/null
+++ b/.github/workflows/auto-author-assign.yml
@@ -0,0 +1,14 @@
+name: "PR Triage"
+on:
+  pull_request_target:
+    types: [opened, reopened, ready_for_review, locked]
+
+
+permissions:
+  pull-requests: write
+  contents: read
+
+jobs:
+  assign-author:
+    uses: vyos/.github/.github/workflows/assign-author.yml@feature/T6349-reusable-workflows
+    secrets: inherit
diff --git a/.github/workflows/chceck-pr-message.yml b/.github/workflows/chceck-pr-message.yml
new file mode 100644
index 0000000..e7e4569
--- /dev/null
+++ b/.github/workflows/chceck-pr-message.yml
@@ -0,0 +1,18 @@
+---
+name: Check pull request message format
+
+on:
+  pull_request:
+    branches:
+      - current
+      - crux
+      - equuleus
+
+permissions:
+  pull-requests: write
+  contents: read
+
+jobs:
+  check-pr-title:
+    uses: vyos/.github/.github/workflows/check-pr-message.yml@feature/T6349-reusable-workflows
+    secrets: inherit
diff --git a/.github/workflows/check-pr-conflicts.yml b/.github/workflows/check-pr-conflicts.yml
new file mode 100644
index 0000000..0c659e6
--- /dev/null
+++ b/.github/workflows/check-pr-conflicts.yml
@@ -0,0 +1,14 @@
+
+name: "PR Conflicts checker"
+on:
+  pull_request_target:
+    types: [synchronize]
+
+permissions:
+  pull-requests: write
+  contents: read
+
+jobs:
+  check-pr-conflict-call:
+    uses: vyos/.github/.github/workflows/check-pr-merge-conflict.yml@feature/T6349-reusable-workflows
+    secrets: inherit
diff --git a/.github/workflows/check-stale.yml b/.github/workflows/check-stale.yml
new file mode 100644
index 0000000..b5ec533
--- /dev/null
+++ b/.github/workflows/check-stale.yml
@@ -0,0 +1,13 @@
+name: "Issue and PR stale management"
+on:
+  schedule:
+  - cron: "0 0 * * *"
+
+permissions:
+  pull-requests: write
+  contents: read
+
+jobs:
+  stale:
+    uses: vyos/.github/.github/workflows/check-stale.yml@feature/T6349-reusable-workflows
+    secrets: inherit
diff --git a/.github/workflows/check-unused-imports.yml b/.github/workflows/check-unused-imports.yml
new file mode 100644
index 0000000..aada264
--- /dev/null
+++ b/.github/workflows/check-unused-imports.yml
@@ -0,0 +1,15 @@
+name: Check for unused imports using Pylint
+on:
+  pull_request:
+    branches:
+      - current
+      - sagitta
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+jobs:
+  check-unused-imports:
+    uses: vyos/.github/.github/workflows/check-unused-imports.yml@feature/T6349-reusable-workflows
+    secrets: inherit
diff --git a/.github/workflows/codeql.yml b/.github/workflows/codeql.yml
new file mode 100644
index 0000000..f647278
--- /dev/null
+++ b/.github/workflows/codeql.yml
@@ -0,0 +1,22 @@
+name: "Perform CodeQL Analysis"
+
+on:
+  push:
+    branches: [ "current", "sagitta", "equuleus" ]
+  pull_request:
+    # The branches below must be a subset of the branches above
+    branches: [ "current" ]
+  schedule:
+    - cron: '22 10 * * 0'
+
+permissions:
+  actions: read
+  contents: read
+  security-events: write
+
+jobs:
+  codeql-analysis-call:
+    uses: vyos/.github/.github/workflows/codeql-analysis.yml@feature/T6349-reusable-workflows
+    secrets: inherit
+    with:
+      languages: "['python']"
diff --git a/.github/workflows/label-backport.yml b/.github/workflows/label-backport.yml
new file mode 100644
index 0000000..9192b81
--- /dev/null
+++ b/.github/workflows/label-backport.yml
@@ -0,0 +1,12 @@
+name: Mergifyio backport
+
+on: [issue_comment]
+
+permissions:
+  pull-requests: write
+  contents: read
+
+jobs:
+  mergifyio-backport:
+    uses: vyos/.github/.github/workflows/label-backport.yml@feature/T6349-reusable-workflows
+    secrets: inherit
diff --git a/.github/workflows/linit-j2.yml b/.github/workflows/linit-j2.yml
new file mode 100644
index 0000000..364a65a
--- /dev/null
+++ b/.github/workflows/linit-j2.yml
@@ -0,0 +1,18 @@
+---
+name: J2 Lint
+
+on:
+  pull_request:
+    branches:
+      - current
+      - crux
+      - equuleus
+
+permissions:
+  pull-requests: write
+  contents: read
+
+jobs:
+  j2lint:
+    uses: vyos/.github/.github/workflows/lint-j2.yml@feature/T6349-reusable-workflows
+    secrets: inherit
diff --git a/CODEOWNERS b/CODEOWNERS
new file mode 100644
index 0000000..1913942
--- /dev/null
+++ b/CODEOWNERS
@@ -0,0 +1 @@
+* @vyos/reviewers
\ No newline at end of file
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000..48cdbd5
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,165 @@
+# Contributing to VyOS
+
+You wan't to help us improve VyOS? This is awesome!
+
+We accept any kind of Pull Requests on GitHub. In order to get your changes into
+the main repository as smooth as possible please take yourself some time and
+review this contribution guideline.
+
+The following paragraphs are an excerpt from our Documentation.
+
+## Submit a Patch
+
+Patches are always more than welcome. To have a clean and easy to maintain
+repository we have some guidelines when working with Git. A clean repository
+eases the automatic generation of a changelog file.
+
+A good approach for writing commit messages is actually to have a look at the
+file(s) history by invoking git log path/to/file.txt.
+
+### Prepare patch/commit
+
+In a big system, such as VyOS, that is comprised of multiple components, it’s
+impossible to keep track of all the changes and bugs/feature requests in one’s
+head. We use a bugtracker named Phorge (formerly known Phabricator) for it (“issue tracker” would
+be a better term, but this one stuck).
+
+The information is used in three ways:
+
+* Keep track of the progress (what we have already done in this branch and
+  what  we still need to do).
+* Prepare automatic release notes for upcoming releases
+* Help future maintainers of VyOS (it could be you!) to find out why certain
+  things have been changed in the codebase or why certain features have been
+  added
+
+To make this approach work, every change must be associated with a task number
+(prefixed with **T**) and a component. If there is no bug report/feature
+request for the changes you are going to make, you have to create a development portal
+task first. Once there is an entry in the development portal, you should reference its id
+in your commit message, as shown below:
+
+* `ddclient: T1030: auto create runtime directories`
+* `Jenkins: add current Git commit ID to build description`
+
+If there is no [development portal](https://vyos.dev) reference in the
+commits of your pull request, we have to ask you to amend the commit message.
+Otherwise we will have to reject it.
+
+## Writing good commit messages
+
+The format should be and is inspired by this very good and detailed
+[Git documentation](https://git-scm.com/book/ch5-2.html), it is also worth
+reading https://chris.beams.io/posts/git-commit/.
+
+This is nothing VyOS specific - it is more a general topic for distributed
+development environments.
+
+* A single, short, summary of the commit (recommended 50 characters or less,
+  not exceeding 80 characters) containing a prefix of the changed component
+  and the corresponding development portal reference e.g. `snmp: T1111:` or
+  `ethernet: T2222:` - multiple components could be concatenated as in `snmp:
+  ethernet: T3333`
+* In some contexts, the first line is treated as the subject of an email and
+  the rest of the text as the body. The blank line separating the summary from
+  the body is critical (unless you omit the body entirely); tools like rebase
+  can get confused if you run the two together.
+* Followed by a message which describes all the details like:
+  * What/why/how something has been changed, makes everyone’s life easier when
+    working with `git bisect`
+  * All text of the commit message should be wrapped at 72 characters if
+    possible which makes reading commit logs easier with git log on a standard
+	terminal (which happens to be 80x25)
+  * If applicable a reference to a previous commit should be made linking those
+    commits nicely when browsing the history: `After commit abcd12ef ("snmp:
+	this is a headline") a Python import statement is missing, throwing the
+	following exception: ABCDEF`
+* Always use the `-x` option to the `git cherry-pick` command when back or
+  forward porting an individual commit. This automatically appends the line:
+  `(cherry picked from commit <ID>)` to the original authors commit message
+  making it easier when bisecting problems.
+* Every change set must be consistent (self containing)! Do not fix multiple
+  bugs in a single commit. If you already worked on multiple fixes in the same
+  file use git add –patch to only add the parts related to the one issue into
+  your upcoming commit.
+  
+## Bug Report/Issue
+Issues or bugs are found in any software project. VyOS is not an exception.
+
+All issues should be reported to the developers. This lets the developers know
+what is not working properly. Without this sort of feedback every developer
+will believe that everything is working correctly.
+
+### I have found a bug, what should I do?
+
+When you believe you have found a bug, it is always a good idea to verify the
+issue prior to opening a bug request.
+
+* Consult our [Documentation](https://docs.vyos.io) to ensure that you have
+  configured your system correctly
+* Get community support via [Slack](https://slack.vyos.io) or our online
+  [Forum](https://forum.vyos.io)
+
+#### Ensure the problem is reproducible
+
+When you are able to verify that it is actually a bug, spend some time to
+document how to reproduce the issue. This documentation can be invaluable.
+
+When you wish to have a developer fix a bug that you found, helping them
+reproduce the issue is beneficial to everyone. Be sure to include information
+about the hardware you are using, commands that you were running, any other
+activities that you may have been doing at the time. This additional
+information can be very useful.
+
+* What were you attempting to achieve?
+* What was the configuration prior to the change?
+* What commands did you use? Use e.g. ``show configuration commands``
+
+#### Include output
+
+The output you get when you find a bug can provide lots of information. If you
+get an error message on the screen, copy it exactly. Having the exact message
+can provide detail that the developers can use. Like wise if you have any log
+messages that also are from the time of the issue, include those. They may
+also contain information that is helpful for the development team.
+
+### Reporting
+
+In order to open up a bug-report/feature request you need to create yourself
+an account in the [development portal](https://vyos.dev). On the left
+side of the specific project (VyOS 1.2 or VyOS 1.3) you will find quick-links
+for opening a bug-report/feature request.
+
+* Provide as much information as you can
+* Which version of VyOS are you using? Use operational level command:
+  ``show version``
+* How can we reproduce this Bug? Please include a CLI configuration, you can
+  use ``show configuration command | strip-private`` to remove sensitive
+  information before publishing.
+
+## Feature Request
+
+You have an idea of how to make VyOS better or you are in need of a specific
+feature which all users of VyOS would benefit from? To send a feature request
+please search the [development portal](https://vyos.dev) if there is already a
+request pending. You can enhance it or if you don't find one, create a new one
+by use the quick link in the left side under the specific project.
+
+## Code Contribution
+
+For contributing code to VyOS please take a short moment and review the guideline
+outlined in our Documentation at
+https://docs.vyos.io/en/latest/contributing/development.html#submit-a-patch
+
+### Coding Guidelines
+
+We have some small coding guidelines which are defined in a separate section of
+at https://docs.vyos.io/en/latest/contributing/development.html#coding-guidelines.
+The guidelines cover how to create the necessary XML structure for new features
+and also how to read in the code from the CLI into the Python based scripting
+backend.
+
+Thank you for taking the time reading this guide.
+
+It might also worth browsing our [Blog](https://blog.vyos.io) for additional
+info and updates.