diff options
| -rw-r--r-- | .github/PULL_REQUEST_TEMPLATE.md | 60 | ||||
| -rw-r--r-- | .github/labeler.yml | 12 | ||||
| -rw-r--r-- | .github/workflows/add-pr-labels.yml | 19 | ||||
| -rw-r--r-- | .github/workflows/auto-author-assign.yml | 14 | ||||
| -rw-r--r-- | .github/workflows/chceck-pr-message.yml | 18 | ||||
| -rw-r--r-- | .github/workflows/check-pr-conflicts.yml | 14 | ||||
| -rw-r--r-- | .github/workflows/check-stale.yml | 13 | ||||
| -rw-r--r-- | .github/workflows/check-unused-imports.yml | 15 | ||||
| -rw-r--r-- | .github/workflows/codeql.yml | 22 | ||||
| -rw-r--r-- | .github/workflows/label-backport.yml | 12 | ||||
| -rw-r--r-- | .github/workflows/linit-j2.yml | 18 | ||||
| -rw-r--r-- | CODEOWNERS | 1 | ||||
| -rw-r--r-- | CONTRIBUTING.md | 165 |
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. |