updated to remove develop

README.md

@@ -2,7 +2,7 @@
 
 [![CircleCI](https://circleci.com/gh/ThreeMammals/Ocelot.svg?style=svg)](https://circleci.com/gh/ThreeMammals/Ocelot)
 
-[![Coverage Status](https://coveralls.io/repos/github/ThreeMammals/Ocelot/badge.svg?branch=develop)](https://coveralls.io/github/ThreeMammals/Ocelot?branch=develop)
+[![Coverage Status](https://coveralls.io/repos/github/ThreeMammals/Ocelot/badge.svg?branch=master)](https://coveralls.io/github/ThreeMammals/Ocelot?branch=master)
 
 
 

docker/Dockerfile.base

@@ -1,4 +1,5 @@
 # this is the dockerfile that create the ocelot build container
+# build with the docker-build.sh file in this folder
 FROM mcr.microsoft.com/dotnet/core/sdk:3.1-bionic AS build
 
 RUN apt install gnupg ca-certificates

docker/Dockerfile.build

@@ -1,3 +1,6 @@
+# call from ocelot repo root with
+# docker build -f ./docker/Dockerfile.build .
+
 FROM mijitt0m/ocelot-build:0.0.1
 
 WORKDIR /src

docker/Dockerfile.release

@@ -1,4 +1,4 @@
-# call from root with
+# call from ocelot repo root with
 # docker build --build-arg OCELOT_NUTGET_API_KEY=$OCELOT_NUTGET_API_KEY --build-arg OCELOT_GITHUB_API_KEY=$OCELOT_GITHUB_API_KEY -f ./docker/Dockerfile.release .
 
 FROM mijitt0m/ocelot-build:0.0.1

docker/docker-build.sh

@@ -1,5 +1,5 @@
 # this script build the ocelot docker file
-docker build -t mijitt0m/ocelot-build .
+docker build -t mijitt0m/ocelot-build -f Dockerfile.base .
 echo $DOCKER_PASS | docker login -u $DOCKER_USER --password-stdin
 docker tag mijitt0m/ocelot-build mijitt0m/ocelot-build:0.0.1
 docker push mijitt0m/ocelot-build:latest

docs/building/building.rst

@@ -1,10 +1,10 @@
 Building
 ========
 
-* You'll generally want to run the `./build.ps1` script. This will compile, run unit and acceptance tests and build the output packages locally. Output will got to the `./artifacts` directory.
+* The best way to build Ocelot is using the Dockerfile.build file which can be found in the docker folder in Ocelot root. Use the following command `docker build -f ./docker/Dockerfile.build .`.
 
-* The other `./*.ps1` scripts perform subsets of the build process, if you don't want to run the full build.
+* You'll can run the `./build.ps1` or `./build.sh` script depending on your OS. This will compile, run unit and acceptance tests and build the output packages locally. Output will got to the `./artifacts` directory.
 
-* The release process works best with GitFlow branching; this allows us to publish every development commit to an unstable feed with a unique SemVer version, and then choose when to release to a stable feed.
+* There is a Makefile to make it easier to call the various targers in `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 VS2017 with the latest .NET Core SDK.
+* Alternatively you can build the project in VS2019 with the latest .NET Core SDK.

docs/building/overview.rst

@@ -1,4 +1,4 @@
 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 `AppVeyor <https://www.appveyor.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 <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.

docs/building/releaseprocess.rst

@@ -1,13 +1,16 @@
 Release process
 ===============
 
+* The release process works best with GitHubFlow branching. 
+* Contributors can do whatever they want on PRs and merges to master 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. 
 
 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 :) 
 
-3. When the user is happy with their work they can create a pull request 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 user is happy with their work they can create a pull request against master 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.
 
 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?
@@ -16,23 +19,17 @@ Ocelot uses the following process to accept work into the NuGet packages.
 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.
-    - Builds for Windows, Mac and Linux must have passed.
-    - Builds for Windows, Mac and Linux must not have slowed down dramatically.
+    - 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. After the PR is merged the GitHub issue must be labelled as merged. The merge will trigger an alpha build on the develop branch with these changes that will get pushed to NuGet. You can import this and test it manually should you wish.
+5. After the PR is merged to master the release process will begin which builds the code, versions it, pushes artifacts to GitHub and NuGet packages to NuGet.
 
-6. When the Ocelot team is ready to create a release they will checkout a new release branch with the version from the latest develop build. So look in AppVeyor for the latest develop semver number and checkout a new branch e.g. git checkout -b release/13.1.0 and push this to the remote. Wait for it to build and then merge this branch back into master.
-
-7. Wait for the master build to complete. When it has go to the AppVeyor UI and find the build and click the Deploy link in the top right hand corner. Select release preparation from the environment drop down and click deploy. This will send the release information to GitHub releases. 
-
-8. Go to GitHub releases and find the version you have just released. It will look something like 13.0.0+31.build.1783. Remove +31.build.1783 (or whatever you get) from all the input fields so you are just left with 13.0.0. Untick This is a pre release and click release. This will trigger a build from AppVeyor that downloads the release artifacts from GitHub and publishes them to the stable NuGet feed. All being well you should find your new package on NuGet within 30 minutes. You might also want to manually add the issue numbers of what has been merged so people can see what changed in this release.
-
-9. The final step is to go back to GitHub and close any issues that were labelled as merged. 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>`_.
+6. 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>`_.
 
 Notes
 -----
 
-All NuGet package builds are done with AppVeyor `here <https://ci.appveyor.com/project/TomPallister/ocelot-fcfpb>_` and all releases are done from `here <https://ci.appveyor.com/project/TomPallister/ocelot-ayj4w>_`. We also build Ocelot on Travis `here <https://travis-ci.org/ThreeMammals/Ocelot>`_ but this is only to make sure it is building on multiple OS.
+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>_`.
 
-Only Ocelot core team members can merge PRs and create release branches. Only TomPallister can merge releases into master 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.
+Only TomPallister can merge releases into master 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.

docs/features/caching.rst

@@ -32,7 +32,7 @@ Finally in order to use caching on a route in your ReRoute configuration add thi
 
 In this example ttl seconds is set to 15 which means the cache will expire after 15 seconds.
 
-If you look at the example `here <https://github.com/ThreeMammals/Ocelot/blob/develop/test/Ocelot.ManualTest/Program.cs>`_ you can see how the cache manager 
+If you look at the example `here <https://github.com/ThreeMammals/Ocelot/blob/master/test/Ocelot.ManualTest/Program.cs>`_ you can see how the cache manager 
 is setup and then passed into the Ocelot AddCacheManager configuration method. You can use any settings supported by 
 the CacheManager package and just pass them in.
 

docs/features/configuration.rst

@@ -1,7 +1,7 @@
 Configuration
 ============
 
-An example configuration can be found `here <https://github.com/ThreeMammals/Ocelot/blob/develop/test/Ocelot.ManualTest/ocelot.json>`_.
+An example configuration can be found `here <https://github.com/ThreeMammals/Ocelot/blob/master/test/Ocelot.ManualTest/ocelot.json>`_.
 There are two sections to the configuration. An array of ReRoutes and a GlobalConfiguration. 
 The ReRoutes are the objects that tell Ocelot how to treat an upstream request. The Global 
 configuration is a bit hacky and allows overrides of ReRoute specific settings. It's useful

docs/features/graphql.rst

@@ -5,7 +5,7 @@ OK you got me Ocelot doesn't directly support GraphQL but so many people have as
 the `graphql-dotnet <https://github.com/graphql-dotnet/graphql-dotnet>`_ library. 
 
 
-Please see the sample project `OcelotGraphQL <https://github.com/ThreeMammals/Ocelot/tree/develop/samples/OcelotGraphQL>`_. 
+Please see the sample project `OcelotGraphQL <https://github.com/ThreeMammals/Ocelot/tree/master/samples/OcelotGraphQL>`_. 
 Using a combination of the graphql-dotnet project and Ocelot's DelegatingHandler features this is pretty easy to do. 
 However I do not intend to integrate more closely with GraphQL at the moment. Check out the samples readme and that should give
 you enough instruction on how to do this!