-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* Update README.md Review doc. Update by links. Add labels. * Update readme.md: Review doc. Update links * Update building.rst: Review doc * Update overview.rst * Update tests.rst: Review doc. Update links * Update releaseprocess.rst: Update development process * Update bigpicture.rst: Copy Welcoming from README * Update contributing.rst: Add discussions and dev process refs * Update gettingstarted.rst * Update gotchas.rst: Write IIS gotchas * Update notsupported.rst: Add sections. Use more links * Update administration.rst: Review doc. Fix markup. More links * Update authentication.rst: Review doc. Add more links * Update authorization.rst: review. Add "Authorization Middleware" section * Update caching.rst: Review markup. More links * Update claimstransformation.rst: Review doc. Update markdown. Middleware links * Correct spelling error in dev docs * Update configuration.rst: Review the doc. Rewrite "SSL Errors" section * Update delegatinghandlers.rst: Review. More links. Add "Order of Execution" section * Update dependencyinjection.rst: Review the doc. Fix markdown * Update errorcodes.rst: Review. Add "Design" section * Update graphql.rst: Review. Add "Future" section * Update headerstransformation.rst: Review. More links. Rewrite Placeholders & Future sections * Update headerstransformation.rst: Add "Global Headers Transformation" subsection * Update kubernetes.rst: Review. Links. Add K8s logo * Update kubernetes.rst: Add link to the parent feature * Update loadbalancer.rst: Fix markdown. More links * Update logging.rst: More links. Rewrite "Warning" section * Update methodtransformation.rst * Update middlewareinjection.rst: Review. Check links. Add "Future" section * Update qualityofservice.rst: Review markdown * Update ratelimiting.rst: Review. Markdown. Add "Future" section * Update requestaggregation.rst: Review. Fix markdown * Update requestid.rst: Review markdown * Update routing.rst: Review markdown. Simplify code blocks * Update servicediscovery.rst: Review markdown * Update servicefabric.rst: Review markdown * Update tracing.rst: Review markdown. More links * Update websockets.rst: Complete rewrite * Update README.md: Hide Coverage badge. More footnotes * Update README.md: Add "Service Discovery" footnote * Update index.rst: Arrange features. More instructions * Update releaseprocess.rst: Be more pleasant * Update qualityofservice.rst: Add QoS label and footnote * Fix Sphinx build errors & warning. Fix typos * Add bash script * Order feature names ascending * Sync & update scripts
- Loading branch information
Showing
41 changed files
with
1,844 additions
and
1,500 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,11 +1,13 @@ | ||
| Building | ||
| ======== | ||
|
|
||
| * You can also just run `dotnet tool restore && dotnet cake` locally!. Output will got to the `./artifacts` directory. | ||
| * You can also just run ``dotnet tool restore && dotnet cake`` locally! Output will got to the ``./artifacts`` directory. | ||
|
|
||
| * The best way to replicate the CI process is to build Ocelot locally is using the Dockerfile.build file which can be found in the docker folder in Ocelot root. | ||
| * The best way to replicate the CI process is to build Ocelot locally is using the `Dockerfile.build <https://github.com/ThreeMammals/Ocelot/blob/main/docker/Dockerfile.build>`_ file | ||
| which can be found in the `docker <https://github.com/ThreeMammals/Ocelot/tree/main/docker>`_ folder in `Ocelot <https://github.com/ThreeMammals/Ocelot/tree/main>`_ root. | ||
| Use the following command ``docker build --platform linux/amd64 -f ./docker/Dockerfile.build .`` for example. You will need to change the platform flag depending on your platform. | ||
|
|
||
| * There is a Makefile to make it easier to call the various targets in `build.cake`. The scripts are called with **.sh** but can be easily changed to **.ps1** if you are using Windows. | ||
| * There is a `Makefile <https://github.com/ThreeMammals/Ocelot/blob/main/docs/Makefile>`_ to make it easier to call the various targets in `build.cake <https://github.com/ThreeMammals/Ocelot/blob/main/build.cake>`_. | ||
| The scripts are called with **.sh** but can be easily changed to **.ps1** if you are using Windows. | ||
|
|
||
| * Alternatively you can build the project in VS2022 with the latest .NET 7.0 SDK. | ||
| * Alternatively you can build the project in VS2022 with the latest `.NET 7.0 <https://dotnet.microsoft.com/en-us/download/dotnet/7.0>`_ SDK. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,6 @@ | ||
| Overview | ||
| ======== | ||
|
|
||
| This document summarises the build and release process for the project. The build scripts are written using `Cake <http://cakebuild.net/>`_, and are defined in `./build.cake`. The scripts have been designed to be run by either developers locally or by a build server (currently `CircleCi <https://circleci.com//>`_), with minimal logic defined in the build server itself. | ||
| This document summarises the build and release process for the project. | ||
| The build scripts are written using `Cake <https://cakebuild.net/>`_, and they are defined in ``./build.cake``. | ||
| The scripts have been designed to be run by either developers locally or by a build server (currently `CircleCi <https://circleci.com/>`_), with minimal logic defined in the build server itself. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,38 +1,62 @@ | ||
| Release process | ||
| Release Process | ||
| =============== | ||
|
|
||
| * The release process works best with Git Flow branching. | ||
| * Contributors can do whatever they want on PRs and merges to main will result in packages being released to GitHub and NuGet. | ||
| * The release process works best with `Gitflow <https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow>`_ branching. | ||
| * Contributors can do whatever they want on PRs and feature branches to deliver a feature to **develop** branch. | ||
| * Maintainers can do whatever they want on PRs and merges to **main** will result in packages being released to GitHub and NuGet. | ||
|
|
||
| Ocelot uses the following process to accept work into the NuGet packages. | ||
|
|
||
| 1. User creates an issue or picks up an existing issue in GitHub. | ||
| 1. User creates an issue or picks up an `existing issue <https://github.com/ThreeMammals/Ocelot/issues>`_ in GitHub. | ||
| An issue can be created by converting `discussion <https://github.com/ThreeMammals/Ocelot/discussions>`_ topics if necessary and agreed upon. | ||
|
|
||
| 2. User creates a fork and branches from this (unless a member of core team, they can just create a branch on the main repo) e.g. feat/xxx, fix/xxx etc. It doesn't really matter what the xxx is. It might make sense to use the issue number and maybe a short description. I don't care as long as it has (feat, fix, refactor)/xxx :) | ||
| 2. User creates a fork and branches from this (unless a member of core team, they can just create a branch on the head repo) e.g. ``feature/xxx``, ``bug/xxx`` etc. | ||
| It doesn't really matter what the "xxx" is. It might make sense to use the issue number and maybe a short description. | ||
|
|
||
| 3. When the user is happy with their work they can create a pull request against develop in GitHub with their changes. The user must follow the `SemVer <https://semver.org/>`_ support for this is provided by `GitVersion <https://gitversion.readthedocs.io/en/latest/>`_. So if you need to make breaking changes please make sure you use the correct commit message so GitVersion uses the correct semver tags. Do not manually tag the Ocelot repo this will break things. | ||
| 3. When the contributor is happy with their work they can create a pull request against **develop** in GitHub with their changes. | ||
|
|
||
| 4. The Ocelot team will review the PR and if all is good merge it, else they will suggest feedback that the user will need to act on. In order to speed up getting a PR the user should think about the following. | ||
| - Have I covered all my changes with tests at unit and acceptance level? | ||
| - Have I updated any documentation that my changes may have affected? | ||
| - Does my feature make sense, have I checked all of Ocelot's other features to make sure it doesn't already exist? | ||
| 4. The maintainer must follow the `SemVer <https://semver.org/>`_ support for this is provided by `GitVersion <https://gitversion.net/docs/>`_. | ||
| So if the maintainer needs to make breaking changes, be sure to use the correct commit message, so **GitVersion** uses the correct **SemVer** tags. | ||
| Do not manually tag the Ocelot repo: this will break things! | ||
|
|
||
| In order for a PR to be merged the following must have occured. | ||
| - All new code is covered by unit tests. | ||
| - All new code has at least 1 acceptance test covering the happy path. | ||
| - Tests must have passed. | ||
| - Build must not have slowed down dramatically. | ||
| - The main Ocelot package must not have taken on any non MS dependencies. | ||
| 5. The Ocelot team will review the PR and if all is good merge it, else they will suggest feedback that the user will need to act on. | ||
|
|
||
| 5. After the PR is merged to develop the Ocelot NuGet packages will not be updated until a release is created. | ||
| In order to speed up getting a PR the contributor should think about the following: | ||
|
|
||
| 6. When enough work has been completed to justify a new release. Develop will be merged into main the release process will begin which builds the code, versions it, pushes artifacts to GitHub and NuGet packages to NuGet. | ||
| - Have I covered all my changes with tests at unit and acceptance level? | ||
| - Have I updated any documentation that my changes may have affected? | ||
| - Does my feature make sense, have I checked all of Ocelot's other features to make sure it doesn't already exist? | ||
|
|
||
| 7. The final step is to go back to GitHub and close any issues that are now fixed. You should see something like this in`GitHub <https://github.com/ThreeMammals/Ocelot/releases/tag/13.0.0>`_ and this in `NuGet <https://www.nuget.org/packages/Ocelot/13.0.0>`_. | ||
| In order for a PR to be merged the following must have occured: | ||
|
|
||
| - All new code is covered by unit tests. | ||
| - All new code has at least 1 acceptance test covering the happy path. | ||
| - Tests must have passed locally. | ||
| - Build must have green status. | ||
| - Build must not have slowed down dramatically. | ||
| - The main Ocelot package must not have taken on any non MS dependencies. | ||
|
|
||
| 6. After the PR is merged to **develop** the Ocelot NuGet packages will not be updated until a release is created. | ||
|
|
||
| 7. When enough work has been completed to justify a new release, | ||
| **develop** branch will be merged into **main** as **release/xxx** branch, the release process will begin which builds the code, versions it, pushes artifacts to GitHub and NuGet packages to NuGet. | ||
|
|
||
| 8. The final step is to go back to GitHub and close any issues that are now fixed. | ||
| **Note**: All linked issues to the PR in **Development** settings (right side PR settings) will be closed automatically while merging the PR. | ||
| It is imperative that developer uses the "**Link an issue from this repository**" pop-up dialog of the **Development** settings! | ||
|
|
||
| Notes | ||
| ----- | ||
|
|
||
| All NuGet package builds & releases are done with CircleCI `here <https://circleci.com/gh/ThreeMammals>_` and all releases are done from `here <https://ci.appveyor.com/project/TomPallister/ocelot-ayj4w>_`. | ||
| All NuGet package builds and releases are done with CircleCI, see `Pipelines - ThreeMammals/Ocelot <https://circleci.com/gh/ThreeMammals/Ocelot/>`_. | ||
|
|
||
| Only Tom Pallister (owner) and Ocelot Core Team members (maintainers) can merge releases into **main** at the moment. | ||
| This is to ensure there is a final `quality gate <#quality-gates>`_ in place. Tom is mainly looking for security issues on the final merge. | ||
|
|
||
| We **do** follow this development and release process! | ||
| If anything is unclear or you get stuck in the process, please contact the `Ocelot Core Team <https://github.com/orgs/ThreeMammals/teams/ocelot-core>`_ members or repository maintainers. | ||
|
|
||
| Quality Gates | ||
| ------------- | ||
|
|
||
| Only TomPallister can merge releases into main at the moment. This is to ensure there is a final quality gate in place. Tom is mainly looking for security issues on the final merge. | ||
| To be developed... |
Oops, something went wrong.