diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c839566ee9..eeadf7b8b2 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -2,154 +2,5 @@ Thanks for your interest in contributing to the Open Policy Agent (OPA) project! -# Where to start? - -If you have questions, comments, or requests please file an issue on GitHub. - -If you want to contribute code and you are new to the Go programming language, check out -the [DEVELOPMENT.md](./docs/devel/DEVELOPMENT.md) reference for help getting started. - -We currently welcome contributions of all kinds. For example: - -- Development of features, bug fixes, and other improvements. -- Documentation including reference material and examples. -- Bug and feature reports. - -# Contribution process - -Small bug fixes (or other small improvements) can be submitted directly via a Pull Request on GitHub. -You can expect at least one of the OPA maintainers to respond quickly. - -Before submitting large changes, please open an issue on GitHub outlining: - -- The use case that your changes are applicable to. -- Steps to reproduce the issue(s) if applicable. -- Detailed description of what your changes would entail. -- Alternative solutions or approaches if applicable. - -Use your judgement about what constitutes a large change. If you aren't sure, send a message to the -OPA slack or submit an issue on GitHub. - -## Code Contributions - -If you are contributing code, please consider the following: - -- Most changes should be accompanied with tests. -- All commits must be signed off (see next section). -- Related commits must be squashed before they are merged. -- All tests must pass and there must be no warnings from the `make - check` target. - -If you are new to Go, consider reading [Effective -Go](https://golang.org/doc/effective_go.html) and [Go Code Review -Comments](https://github.com/golang/go/wiki/CodeReviewComments) for -guidance on writing idiomatic Go code. - -When you implement new features in OPA, consider whether the -types/functions you are adding need to be exported. Prefer -unexported types and functions as much as possible. - -If you need to share logic across multiple OPA packages, consider -implementing it inside of the -`github.com/open-policy-agent/opa/internal` package. The `internal` -package is not visible outside of OPA. - -Avoid adding thirdparty dependencies (vendoring). OPA is designed to be minimal, -lightweight, and easily embedded. Vendoring may make features _easier_ to -implement however they come with their own cost for both OPA developers and -OPA users (e.g., vendoring conflicts, security, debugging, etc.) - -## Commit Messages - -Commit messages should explain *why* the changes were made and should probably look like this: - -``` -Description of the change in 50 characters or less - -More detail on what was changed. Provide some background on the issue -and describe how the changes address the issue. Feel free to use multiple -paragraphs but please keep each line under 72 characters or so. -``` - -If your changes are related to an open issue (bug or feature), please include -the following line at the end of your commit message: - -``` -Fixes # -``` - -If the changes are isolated to a specific OPA package or directory please -include a prefix on the first line of the commit message with the following -format: - -``` -: -``` - -For example, a change to the `ast` package: -``` -ast: Fix X when Y happens - - - -Fixes: #123 -Signed-off-by: Random J Developer -``` - -or a change in the OPA website content (found in `./docs/website/**`: -``` -docs/website: Add X to homepage for Y - - - -Fixes: #456 -Signed-off-by: Random J Developer -``` - -## Developer Certificate Of Origin - -The OPA project requires that contributors sign off on changes submitted to OPA repositories. -The [Developer Certificate of Origin (DCO)](https://developercertificate.org/) is a simple way to certify that you wrote or have the right to submit the code you are contributing to the project. - -The DCO is a standard requirement for Linux Foundation and CNCF projects. - -You sign-off by adding the following to your commit messages: - - This is my commit message - - Signed-off-by: Random J Developer - -Git has a `-s` command line option to do this automatically. - - git commit -s -m 'This is my commit message' - -You can find the full text of the DCO here: https://developercertificate.org/ - -## Code Review - -Before a Pull Request is merged, it will undergo code review from other members -of the OPA community. In order to streamline the code review process, when -amending your Pull Request in response to a review, do not squash your changes -into relevant commits until it has been approved for merge. This allows the -reviewer to see what changes are new and removes the need to wade through code -that has not been modified to search for a small change. - -When adding temporary patches in response to review comments, consider -formatting the message subject like one of the following: -- `Fixup into commit (squash before merge)` -- `Fixed changes requested by @username (squash before merge)` -- `Amended (squash before merge)` - -The purpose of these formats is to provide some context into the reason the -temporary commit exists, and to label it as needing squashed before a merge -is performed. - -It is worth noting that not all changes need be squashed before a merge is -performed. Some changes made as a result of review stand well on their own, -independent of other commits in the series. Such changes should be made into -their own commit and added to the PR. - -If your Pull Request is small though, it is acceptable to squash changes during -the review process. Use your judgement about what constitutes a small Pull -Request. If you aren't sure, send a message to the OPA slack or post a comment -on the Pull Request. +Please refer to [OPA's contribution guidelines](https://www.openpolicyagent.org/docs/edge/contributing/) +to find out how you can help. diff --git a/docs/content/contributing.md b/docs/content/contributing.md new file mode 100644 index 0000000000..72af8de0db --- /dev/null +++ b/docs/content/contributing.md @@ -0,0 +1,167 @@ +--- +title: How to contribute +kind: contrib +weight: 1 +--- + +Thanks for your interest in contributing to the Open Policy Agent project! + +## Where to start? + +If you have questions, comments, or requests please file [an issue on +GitHub](https://github.com/open-policy-agent/opa/issues). + +If you want to contribute code and you are new to the Go programming language, check out +the [development reference](../development/) for help getting started. + +We currently welcome contributions of all kinds. For example: + +- Development of features, bug fixes, and other improvements. +- Documentation including reference material and examples. +- Bug and feature reports. + +## Contribution process + +Small bug fixes (or other small improvements) can be submitted directly via a +[Pull Request](https://github.com/open-policy-agent/opa/pulls) on GitHub. +You can expect at least one of the OPA maintainers to respond quickly. + +Before submitting large changes, please open an issue on GitHub outlining: + +- The use case that your changes are applicable to. +- Steps to reproduce the issue(s) if applicable. +- Detailed description of what your changes would entail. +- Alternative solutions or approaches if applicable. + +Use your judgement about what constitutes a large change. If you aren't sure, +send a message to the [OPA slack](https://slack.openpolicyagent.org/) or submit +[an issue on GitHub](https://github.com/open-policy-agent/opa/issues). + +### Code Contributions + +If you are contributing code, please consider the following: + +- Most changes should be accompanied with tests. +- All commits must be signed off (see next section). +- Related commits must be squashed before they are merged. +- All tests must pass and there must be no warnings from the `make + check` target. + +If you are new to Go, consider reading [Effective +Go](https://golang.org/doc/effective_go.html) and [Go Code Review +Comments](https://github.com/golang/go/wiki/CodeReviewComments) for +guidance on writing idiomatic Go code. + +When you implement new features in OPA, consider whether the +types/functions you are adding need to be exported. Prefer +unexported types and functions as much as possible. + +If you need to share logic across multiple OPA packages, consider +implementing it inside of the +`github.com/open-policy-agent/opa/internal` package. The `internal` +package is not visible outside of OPA. + +Avoid adding thirdparty dependencies (vendoring). OPA is designed to be minimal, +lightweight, and easily embedded. Vendoring may make features _easier_ to +implement however they come with their own cost for both OPA developers and +OPA users (e.g., vendoring conflicts, security, debugging, etc.) + +### Commit Messages + +Commit messages should explain *why* the changes were made and should probably +look like this: + +``` +Description of the change in 50 characters or less + +More detail on what was changed. Provide some background on the issue +and describe how the changes address the issue. Feel free to use multiple +paragraphs but please keep each line under 72 characters or so. +``` + +If your changes are related to an open issue (bug or feature), please include +the following line at the end of your commit message: + +``` +Fixes # +``` + +If the changes are isolated to a specific OPA package or directory please +include a prefix on the first line of the commit message with the following +format: + +``` +: +``` + +For example, a change to the `ast` package: +``` +ast: Fix X when Y happens + + + +Fixes: #123 +Signed-off-by: Random J Developer +``` + +or a change in the OPA website content (found in `./docs/content`): +``` +docs/website: Add X to homepage for Y + + + +Fixes: #456 +Signed-off-by: Random J Developer +``` + +### Developer Certificate Of Origin + +The OPA project requires that contributors sign off on changes submitted to OPA +repositories. +The [Developer Certificate of Origin (DCO)](https://developercertificate.org/) +is a simple way to certify that you wrote or have the right to submit the code +you are contributing to the project. + +The DCO is a standard requirement for Linux Foundation and CNCF projects. + +You sign-off by adding the following to your commit messages: + + This is my commit message + + Signed-off-by: Random J Developer + +Git has a `-s` command line option to do this automatically. + + git commit -s -m 'This is my commit message' + +You can find the full text of the DCO here: https://developercertificate.org/ + +### Code Review + +Before a Pull Request is merged, it will undergo code review from other members +of the OPA community. In order to streamline the code review process, when +amending your Pull Request in response to a review, do not squash your changes +into relevant commits until it has been approved for merge. This allows the +reviewer to see what changes are new and removes the need to wade through code +that has not been modified to search for a small change. + +When adding temporary patches in response to review comments, consider +formatting the message subject like one of the following: + +- `Fixup into commit (squash before merge)` +- `Fixed changes requested by @username (squash before merge)` +- `Amended (squash before merge)` + +The purpose of these formats is to provide some context into the reason the +temporary commit exists, and to label it as needing squashed before a merge +is performed. + +It is worth noting that not all changes need be squashed before a merge is +performed. Some changes made as a result of review stand well on their own, +independent of other commits in the series. Such changes should be made into +their own commit and added to the PR. + +If your Pull Request is small though, it is acceptable to squash changes during +the review process. Use your judgement about what constitutes a small Pull +Request. If you aren't sure, send a message to the OPA slack or post a comment +on the Pull Request. diff --git a/docs/content/development.md b/docs/content/development.md new file mode 100644 index 0000000000..9d8f382bd0 --- /dev/null +++ b/docs/content/development.md @@ -0,0 +1,199 @@ +--- +title: Development +kind: contrib +weight: 2 +--- + +OPA is written in the [Go](https://golang.org) programming language. + +If you are not familiar with Go we recommend you read through the [How to Write Go +Code](https://golang.org/doc/code.html) article to familiarize yourself with the standard Go development environment. + +Requirements: + +- Git +- GitHub account (if you are contributing) +- Go (version 1.15+ is supported though older versions are likely to work) +- GNU Make + +## Getting Started + +After cloning the repository, just run `make`. This will: + +- Build the OPA binary. +- Run all of the tests. +- Run all of the static analysis checks. + +If the build was successful, a binary will be produced in the top directory (`opa__`). + +Verify the build was successful with `./opa__ run`. + +You can re-build the project with `make build`, execute all of the tests +with `make test`, and execute all of the performance benchmarks with `make perf`. + +The static analysis checks (e.g., `go fmt`, `golint`, `go vet`) can be run +with `make check`. + +> To correct any imports or style errors run `make fmt`. + +## Workflow + +### Fork, clone, create a branch + +Go to [https://github.com/open-policy-agent/opa](https://github.com/open-policy-agent/opa) and fork the repository +into your account by clicking the "Fork" button. + +Clone the fork to your local machine: + +```bash +git clone git@github.com//opa.git opa +cd opa +git remote add upstream https://github.com/open-policy-agent/opa.git +``` + +Create a branch for your changes. + +```bash +git checkout -b somefeature +``` + +### Developing your change + +Develop your changes and regularly update your local branch against upstream, +for example by rebasing: + +```bash +git fetch upstream +git rebase upstream/main +``` + +> Be sure to run `make check` before submitting your pull request. You +> may need to run `go fmt` on your code to make it comply with standard Go +> style. + + +### Submission + +Commit changes and push to your fork. + +```bash +git commit -s +git push origin somefeature +``` + +> Make sure to use a [good commit message](../contributing/#commit-messages). + +Now, submit a Pull Request from your fork. +See the official [GitHub Documentation](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork) +for instructions to create the request. + +> Hint: You should be prompted to with a "Compare and Pull Request" button +> that mentions your new branch on [https://github.com/open-policy-agent/opa](https://github.com/open-policy-agent/opa) + +Once your Pull Request has been reviewed and signed off please squash your +commits. If you have a specific reason to leave multiple commits in the +Pull Request, please mention it in the discussion. + +> If you are not familiar with squashing commits, see [the following blog post for a good overview](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html). + +## Built-in Functions + +[Built-in Functions](../policy-reference/#built-in-functions) +can be added inside the `topdown` package in this repository. + +Built-in functions may be upstreamed if they are generally useful and provide functionality that would be +impractical to implement natively in Rego (e.g., CIDR arithmetic). Implementations should avoid thirdparty +dependencies. If absolutely necessary, consider importing the code manually into the `internal` package. + +All built-in function implementations must include a test suite. See [test/cases/testdata/helloworld](https://github.com/open-policy-agent/opa/blob/main/test/cases/testdata/helloworld) +in this repository for an example of how to implement tests for your built-in functions. + +## Benchmarks + +Several packages in this repository implement benchmark tests. To execute the +benchmarks you can run `make perf` in the top-level directory. We use the Go +benchmarking framework for all benchmarks. The benchmarks run on every pull +request. + +To help catch performance regressions we also run a batch job that compares the +benchmark results from the tip of main against the last major release. All of +the results are posted and can be viewed +[here](https://opa-benchmark-results.s3.amazonaws.com/index.html). + +## Dependencies + +OPA is a Go module [https://github.com/golang/go/wiki/Modules](https://github.com/golang/go/wiki/Modules) +and dependencies are tracked with the standard [go.mod](../../go.mod) file. + +We also keep a full copy of the dependencies in the [vendor](../../vendor) +directory. All `go` commands from the [Makefile](../../Makefile) will enable +module mode by setting `GO111MODULE=on GOFLAGS=-mod=vendor` which will also +force using the `vendor` directory. + +To update a dependency ensure that `GO111MODULE` is either on, or the repository +qualifies for `auto` to enable module mode. Then simply use `go get ..` to get +the version desired. This should update the [go.mod](../../go.mod) and (potentially) +[go.sum](../../go.sum) files. After this you *MUST* run `go mod vendor` to ensure +that the `vendor` directory is in sync. + +Example workflow for updating a dependency: + +```bash +go get -u github.com/sirupsen/logrus@v1.4.2 # Get the specified version of the package. +go mod tidy # (Somewhat optional) Prunes removed dependencies. +go mod vendor # Ensure the vendor directory is up to date. +``` + +If dependencies have been removed ensure to run `go mod tidy` to clean them up. + +### Tool Dependencies + +Sometimes we use some tools which are versioned and vendored +with OPA as dependencies. For now, we have none, but any we use in the future +should go in [tools.go](../../tools.go). + +More details on the pattern: [https://github.com/go-modules-by-example/index/blob/master/010_tools/README.md](https://github.com/go-modules-by-example/index/blob/master/010_tools/README.md) + +Update these the same way as any other Go package. Ensure that any build script +only uses `go run ./vendor/` to force using the correct version. + +### Go + +If you need to update the version of Go used to build OPA you must update these +files in the root of this repository: + +* `.go-version`- which is used by the Makefile and CI tooling. Put the exact go + version that OPA should use. + +## CI Configuration + +OPA uses Github Actions defined in the [.github/workflows](../../.github/workflows) +directory. + +### Github Action Secrets + +The following secrets are used by the Github Action workflows: + +| Name | Description | +|------|-------------| +| S3_RELEASE_BUCKET | AWS S3 Bucket name to upload `edge` release binaries to. Optional -- If not provided the release upload steps are skipped. | +| AWS_ACCESS_KEY_ID | AWS credentials required to upload to the configured `S3_RELEASE_BUCKET`. Optional -- If not provided the release upload steps are skipped. | +| AWS_SECRET_ACCESS_KEY | AWS credentials required to upload to the configured `S3_RELEASE_BUCKET`. Optional -- If not provided the release upload steps are skipped. | +| DOCKER_IMAGE | Full docker image name (with org) to tag and publish OPA images. Optional -- If not provided the image defaults to `openpolicyagent/opa`. | +| DOCKER_WASM_BUILDER_IMAGE | Full docker image name (with org) to tag and publish WASM builder images. Optional -- If not provided the image defaults to `openpolicyagent/opa-wasm-builder`. | +| DOCKER_USER | Docker username for uploading release images. Will be used with `docker login`. Optional -- If not provided the image push steps are skipped. | +| DOCKER_PASSWORD | Docker password or API token for the configured `DOCKER_USER`. Will be used with `docker login`. Optional -- If not provided the image push steps are skipped. | +| SLACK_NOTIFICATION_WEBHOOK | Slack webhook for sending notifications. Optional -- If not provided the notification steps are skipped. | +| TELEMETRY_URL | URL to inject at build-time for OPA version reporting. Optional -- If not provided the default value in OPA's source is used. | + +### Periodic Workflows + +Some of the Github Action workflows are triggered on a schedule, and not included in the +post-merge, pull-request, etc actions. These are reserved for time consuming or potentially +non-deterministic jobs (race detection tests, fuzzing, etc). + +Below is a list of workflows and links to their status: + +| Workflow | Description | +|----------|-------------| +| [![Nightly](https://github.com/open-policy-agent/opa/workflows/Nightly/badge.svg?branch=main)](https://github.com/open-policy-agent/opa/actions?query=workflow%3A"Nightly") | Runs once per day at 8:00 UTC. | diff --git a/docs/content/monitoring.md b/docs/content/monitoring.md index 4e98bd678c..a61d3f1a68 100644 --- a/docs/content/monitoring.md +++ b/docs/content/monitoring.md @@ -5,9 +5,7 @@ weight: 30 restrictedtoc: true --- -## Monitoring - -### Prometheus +## Prometheus OPA exposes an HTTP endpoint that can be used to collect performance metrics for all API calls. The Prometheus endpoint is enabled by default when you run @@ -60,12 +58,12 @@ The Prometheus endpoint exports Go runtime metrics as well as HTTP request laten | go_threads | gauge | Number of OS threads created. | | http_request_duration_seconds | histogram | A histogram of duration for requests. | -### Health Checks +## Health Checks OPA exposes a `/health` API endpoint that can be used to perform health checks. See [Health API](../rest-api#health-api) for details. -### Status API +## Status API OPA provides a plugin which can push status to a remote service. See [Status API](../management-status) for details. diff --git a/docs/devel/DEVELOPMENT.md b/docs/devel/DEVELOPMENT.md index d5db8bfdcf..a4b718a2ee 100644 --- a/docs/devel/DEVELOPMENT.md +++ b/docs/devel/DEVELOPMENT.md @@ -1,191 +1,4 @@ ## Development -OPA is written in the [Go](https://golang.org) programming language. - -If you are not familiar with Go we recommend you read through the [How to Write Go -Code](https://golang.org/doc/code.html) article to familiarize yourself with the standard Go development environment. - -Requirements: - -- Git -- GitHub account (if you are contributing) -- Go (version 1.14+ is supported though older versions are likely to work) -- GNU Make - -## Getting Started - -After cloning the repository, just run `make`. This will: - -- Build the OPA binary. -- Run all of the tests. -- Run all of the static analysis checks. - -If the build was successful, a binary will be produced in the top directory (`opa__`). - -Verify the build was successful with `./opa__ run`. - -You can re-build the project with `make build`, execute all of the tests -with `make test`, and execute all of the performance benchmarks with `make perf`. - -The static analysis checks (e.g., `go fmt`, `golint`, `go vet`) can be run -with `make check`. - -> To correct any imports or style errors run `make fmt`. - -## Workflow - -1. Go to [https://github.com/open-policy-agent/opa](https://github.com/open-policy-agent/opa) and fork the repository - into your account by clicking the "Fork" button. - -1. Clone the fork to your local machine. - - ```bash - # Note: With Go modules this repo can be in _any_ location, - # and does not need to be in the GOSRC path. - git clone git@github.com//opa.git opa - cd opa - git remote add upstream https://github.com/open-policy-agent/opa.git - ``` - -1. Create a branch for your changes. - - ``` - git checkout -b somefeature - ``` - -1. Update your local branch with upstream. - - ``` - git fetch upstream - git rebase upstream/main - ``` - -1. Develop your changes and regularly update your local branch against upstream. - - - Be sure to run `make check` before submitting your pull request. You - may need to run `go fmt` on your code to make it comply with standard Go - style. - -1. Commit changes and push to your fork. - - ``` - git commit -s - git push origin somefeature - ``` - - > Make sure to use a [good commit message](../../CONTRIBUTING.md#commit-messages) - -1. Submit a Pull Request from your fork. See the official [GitHub Documentation](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork) - for instructions to create the request. - - > Hint: You should be prompted to with a "Compare and Pull Request" button - that mentions your new branch on [https://github.com/open-policy-agent/opa](https://github.com/open-policy-agent/opa) - -1. Once your Pull Request has been reviewed and signed off please squash your - commits. If you have a specific reason to leave multiple commits in the - Pull Request, please mention it in the discussion. - - > If you are not familiar with squashing commits, see [the following blog post for a good overview](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html). - -## Built-in Functions - -[Built-in Functions](https://www.openpolicyagent.org/docs/latest/policy-reference/#built-in-functions) -can be added inside the `topdown` package in this repository. - -Built-in functions may be upstreamed if they are generally useful and provide functionality that would be -impractical to implement natively in Rego (e.g., CIDR arithmetic). Implementations should avoid thirdparty -dependencies. If absolutely necessary, consider importing the code manually into the `internal` package. - -All built-in function implementations must include a test suite. See [test/cases/testdata/helloworld](https://github.com/open-policy-agent/opa/blob/main/test/cases/testdata/helloworld) -in this repository for an example of how to implement tests for your built-in functions. - -## Benchmarks - -Several packages in this repository implement benchmark tests. To execute the -benchmarks you can run `make perf` in the top-level directory. We use the Go -benchmarking framework for all benchmarks. The benchmarks run on every pull -request. - -To help catch performance regressions we also run a batch job that compares the -benchmark results from the tip of main against the last major release. All of -the results are posted and can be viewed -[here](https://opa-benchmark-results.s3.amazonaws.com/index.html). - -## Dependencies - -OPA is a Go module [https://github.com/golang/go/wiki/Modules](https://github.com/golang/go/wiki/Modules) -and dependencies are tracked with the standard [go.mod](../../go.mod) file. - -We also keep a full copy of the dependencies in the [vendor](../../vendor) -directory. All `go` commands from the [Makefile](../../Makefile) will enable -module mode by setting `GO111MODULE=on GOFLAGS=-mod=vendor` which will also -force using the `vendor` directory. - -To update a dependency ensure that `GO111MODULE` is either on, or the repository -qualifies for `auto` to enable module mode. Then simply use `go get ..` to get -the version desired. This should update the [go.mod](../../go.mod) and (potentially) -[go.sum](../../go.sum) files. After this you *MUST* run `go mod vendor` to ensure -that the `vendor` directory is in sync. - -Example workflow for updating a dependency: - -```bash -go get -u github.com/sirupsen/logrus@v1.4.2 # Get the specified version of the package. -go mod tidy # (Somewhat optional) Prunes removed dependencies. -go mod vendor # Ensure the vendor directory is up to date. -``` - -If dependencies have been removed ensure to run `go mod tidy` to clean them up. - - -### Tool Dependencies - -Sometimes we use some tools which are versioned and vendored -with OPA as dependencies. For now, we have none, but any we use in the future -should go in [tools.go](../../tools.go). - -More details on the pattern: [https://github.com/go-modules-by-example/index/blob/master/010_tools/README.md](https://github.com/go-modules-by-example/index/blob/master/010_tools/README.md) - -Update these the same way as any other Go package. Ensure that any build script -only uses `go run ./vendor/` to force using the correct version. - -## Go - -If you need to update the version of Go used to build OPA you must update these -files in the root of this repository: - -* `.go-version`- which is used by the Makefile and CI tooling. Put the exact go - version that OPA should use. - -# CI Configuration - -OPA uses Github Actions defined in the [.github/workflows](../../.github/workflows) -directory. - -## Github Action Secrets - -The following secrets are used by the Github Action workflows: - -| Name | Description | -|------|-------------| -| S3_RELEASE_BUCKET | AWS S3 Bucket name to upload `edge` release binaries to. Optional -- If not provided the release upload steps are skipped. | -| AWS_ACCESS_KEY_ID | AWS credentials required to upload to the configured `S3_RELEASE_BUCKET`. Optional -- If not provided the release upload steps are skipped. | -| AWS_SECRET_ACCESS_KEY | AWS credentials required to upload to the configured `S3_RELEASE_BUCKET`. Optional -- If not provided the release upload steps are skipped. | -| DOCKER_IMAGE | Full docker image name (with org) to tag and publish OPA images. Optional -- If not provided the image defaults to `openpolicyagent/opa`. | -| DOCKER_WASM_BUILDER_IMAGE | Full docker image name (with org) to tag and publish WASM builder images. Optional -- If not provided the image defaults to `openpolicyagent/opa-wasm-builder`. | -| DOCKER_USER | Docker username for uploading release images. Will be used with `docker login`. Optional -- If not provided the image push steps are skipped. | -| DOCKER_PASSWORD | Docker password or API token for the configured `DOCKER_USER`. Will be used with `docker login`. Optional -- If not provided the image push steps are skipped. | -| SLACK_NOTIFICATION_WEBHOOK | Slack webhook for sending notifications. Optional -- If not provided the notification steps are skipped. | -| TELEMETRY_URL | URL to inject at build-time for OPA version reporting. Optional -- If not provided the default value in OPA's source is used. | - -## Periodic Workflows - -Some of the Github Action workflows are triggered on a schedule, and not included in the -post-merge, pull-request, etc actions. These are reserved for time consuming or potentially -non-deterministic jobs (race detection tests, fuzzing, etc). - -Below is a list of workflows and links to their status: - -| Workflow | Description | -|----------|-------------| -| [![Nightly](https://github.com/open-policy-agent/opa/workflows/Nightly/badge.svg?branch=main)](https://github.com/open-policy-agent/opa/actions?query=workflow%3A"Nightly") | Runs once per day at 8:00 UTC. | +The development guide has become part of the Contributing documentation +and can be found [here](https://www.openpolicyagent.org/docs/edge/development/). \ No newline at end of file diff --git a/docs/website/layouts/partials/docs/sidenav.html b/docs/website/layouts/partials/docs/sidenav.html index 992969f1a5..8a44b6a4de 100644 --- a/docs/website/layouts/partials/docs/sidenav.html +++ b/docs/website/layouts/partials/docs/sidenav.html @@ -2,11 +2,12 @@ {{ $allDocs := where site.RegularPages "Section" "docs" }} {{ $docs := where $allDocs ".Params.kind" "eq" "documentation" }} {{ $kubernetes := where $allDocs ".Params.kind" "eq" "kubernetes" }} -{{ $envoy := where $allDocs ".Params.kind" "eq" "envoy" }} +{{ $envoy := where $allDocs ".Params.kind" "eq" "envoy" }} {{ $tutorials := where $allDocs ".Params.kind" "eq" "tutorial" }} {{ $operations := where $allDocs ".Params.kind" "eq" "operations" }} {{ $management := where $allDocs ".Params.kind" "eq" "management" }} -{{ $misc := where $allDocs ".Params.kind" "eq" "misc" }} +{{ $contrib := where $allDocs ".Params.kind" "eq" "contrib" }} +{{ $misc := where $allDocs ".Params.kind" "eq" "misc" }} {{ $pageUrl := .URL }} {{ $isDocsHome := eq .URL $docsHome.URL }} {{ $version := index (split .File.Path "/") 1 }} @@ -44,6 +45,8 @@ {{ partial "docs/sidenav-section.html" ( dict "ctx" . "sectionTitle" "Management APIs" "section" $management "pageUrl" $pageUrl "version" $version ) }} +{{ partial "docs/sidenav-section.html" ( dict "ctx" . "sectionTitle" "Contributing" "section" $contrib "pageUrl" $pageUrl "version" $version ) }} + {{ partial "docs/sidenav-section.html" ( dict "ctx" . "sectionTitle" "Miscellaneous" "section" $misc "pageUrl" $pageUrl "version" $version ) }}