PR to see diff (while we fix this)

.github/FUNDING.yml

@@ -1,3 +1,6 @@
+# AUTO-GENERATED, DO NOT EDIT!
+# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/FUNDING.yml
+
 # These are supported funding model platforms
 
 # github:

.github/ISSUE_TEMPLATE/BUG-REPORT.yml

@@ -1,3 +1,6 @@
+# AUTO-GENERATED, DO NOT EDIT!
+# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/ISSUE_TEMPLATE/BUG-REPORT.yml
+
 description: "Create a bug report"
 labels:
   - bug
@@ -22,7 +25,7 @@ body:
             Guidelines](https://github.com/ory/oathkeeper/blob/master/CONTRIBUTING.md)."
           required: true
         - label:
-            "This issue affects my [Ory Cloud](https://www.ory.sh/) project."
+            "This issue affects my [Ory Network](https://www.ory.sh/) project."
         - label:
             "I have joined the [Ory Community Slack](https://slack.ory.sh)."
         - label:
@@ -86,7 +89,7 @@ body:
   - attributes:
       label: "On which operating system are you observing this issue?"
       options:
-        - Ory Cloud
+        - Ory Network
         - macOS
         - Linux
         - Windows
@@ -97,7 +100,7 @@ body:
   - attributes:
       label: "In which environment are you deploying?"
       options:
-        - Ory Cloud
+        - Ory Network
         - Docker
         - "Docker Compose"
         - "Kubernetes with Helm"

.github/ISSUE_TEMPLATE/DESIGN-DOC.yml

@@ -1,3 +1,6 @@
+# AUTO-GENERATED, DO NOT EDIT!
+# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/ISSUE_TEMPLATE/DESIGN-DOC.yml
+
 description:
   "A design document is needed for non-trivial changes to the code base."
 labels:
@@ -13,8 +16,8 @@ body:
         Ory is leaning heavily on [Google's design docs process](https://www.industrialempathy.com/posts/design-docs-at-google/)
         and [Golang Proposals](https://github.com/golang/proposal).
 
-        Writing a design doc prior to contributing your change ensures that your ideas are checked with
-        the community and maintainers. It will save you a lot of time developing things which might need changed
+        Writing a design doc before contributing your change ensures that your ideas are checked with
+        the community and maintainers. It will save you a lot of time developing things that might need to be changed
         after code reviews, and your pull requests will be merged faster.
     type: markdown
   - attributes:
@@ -33,7 +36,7 @@ body:
             Guidelines](https://github.com/ory/oathkeeper/blob/master/CONTRIBUTING.md)."
           required: true
         - label:
-            "This issue affects my [Ory Cloud](https://www.ory.sh/) project."
+            "This issue affects my [Ory Network](https://www.ory.sh/) project."
         - label:
             "I have joined the [Ory Community Slack](https://slack.ory.sh)."
         - label:
@@ -64,7 +67,7 @@ body:
         This section should start with an overview and then go into details.
         The design doc is the place to write down the trade-offs you made in designing your software. Focus on those trade-offs to produce a useful document with long-term value. That is, given the context (facts), goals and non-goals (requirements), the design doc is the place to suggest solutions and show why a particular solution best satisfies those goals.
 
-        The point of writing a document over a more formal medium is to provide the flexibility to express the problem set at hand in an appropriate manner. Because of this, there is no explicit guidance for how to actually describe the design.
+        The point of writing a document over a more formal medium is to provide the flexibility to express the problem at hand in an appropriate manner. Because of this, there is no explicit guidance on how to actually describe the design.
       label: "The design"
     id: design
     type: textarea
@@ -73,21 +76,21 @@ body:
 
   - attributes:
       description: |
-        If the system under design exposes an API, then sketching out that API is usually a good idea. In most cases, however, one should withstand the temptation to copy-paste formal interface or data definitions into the doc as these are often verbose, contain unnecessary detail and quickly get out of date. Instead focus on the parts that are relevant to the design and its trade-offs.
+        If the system under design exposes an API, then sketching out that API is usually a good idea. In most cases, however, one should withstand the temptation to copy-paste formal interface or data definitions into the doc as these are often verbose, contain unnecessary detail and quickly get out of date. Instead, focus on the parts that are relevant to the design and its trade-offs.
       label: "APIs"
     id: apis
     type: textarea
 
   - attributes:
       description: |
-        Systems that store data should likely discuss how and in what rough form this happens. Similar to the advice on APIs, and for the same reasons, copy-pasting complete schema definitions should be avoided. Instead focus on the parts that are relevant to the design and its trade-offs.
+        Systems that store data should likely discuss how and in what rough form this happens. Similar to the advice on APIs, and for the same reasons, copy-pasting complete schema definitions should be avoided. Instead, focus on the parts that are relevant to the design and its trade-offs.
       label: "Data storage"
     id: persistence
     type: textarea
 
   - attributes:
       description: |
-        Design docs should rarely contain code, or pseudo-code except in situations where novel algorithms are described. As appropriate, link to prototypes that show the implementability of the design.
+        Design docs should rarely contain code, or pseudo-code except in situations where novel algorithms are described. As appropriate, link to prototypes that show the feasibility of the design.
       label: "Code and pseudo-code"
     id: pseudocode
     type: textarea
@@ -98,9 +101,9 @@ body:
 
         On one end of the extreme is the “greenfield software project”, where all we know are the goals, and the solution can be whatever makes the most sense. Such a document may be wide-ranging, but it also needs to quickly define a set of rules that allow zooming in on a manageable set of solutions.
 
-        On the other end are systems where the possible solutions are very well defined, but it isn’t at all obvious how they could even be combined to achieve the goals. This may be a legacy system that is difficult to change and wasn’t designed to do what you want it to do or a library design that needs to operate within the constraints of the host programming language.
+        On the other end are systems where the possible solutions are very well defined, but it isn't at all obvious how they could even be combined to achieve the goals. This may be a legacy system that is difficult to change and wasn't designed to do what you want it to do or a library design that needs to operate within the constraints of the host programming language.
 
-        In this situation you may be able to enumerate all the things you can do relatively easily, but you need to creatively put those things together to achieve the goals. There may be multiple solutions, and none of them are really great, and hence such a document should focus on selecting the best way given all identified trade-offs.
+        In this situation, you may be able to enumerate all the things you can do relatively easily, but you need to creatively put those things together to achieve the goals. There may be multiple solutions, and none of them are great, and hence such a document should focus on selecting the best way given all identified trade-offs.
       label: "Degree of constraint"
     id: constrait
     type: textarea
@@ -109,7 +112,7 @@ body:
       description: |
         This section lists alternative designs that would have reasonably achieved similar outcomes. The focus should be on the trade-offs that each respective design makes and how those trade-offs led to the decision to select the design that is the primary topic of the document.
 
-        While it is fine to be succinct about solution that ended up not being selected, this section is one of the most important ones as it shows very explicitly why the selected solution is the best given the project goals and how other solutions, that the reader may be wondering about, introduce trade-offs that are less desirable given the goals.
+        While it is fine to be succinct about a solution that ended up not being selected, this section is one of the most important ones as it shows very explicitly why the selected solution is the best given the project goals and how other solutions, that the reader may be wondering about, introduce trade-offs that are less desirable given the goals.
 
       label: Alternatives considered
     id: alternatives

.github/ISSUE_TEMPLATE/FEATURE-REQUEST.yml

@@ -1,3 +1,6 @@
+# AUTO-GENERATED, DO NOT EDIT!
+# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/ISSUE_TEMPLATE/FEATURE-REQUEST.yml
+
 description:
   "Suggest an idea for this project without a plan for implementation"
 labels:
@@ -26,7 +29,7 @@ body:
             Guidelines](https://github.com/ory/oathkeeper/blob/master/CONTRIBUTING.md)."
           required: true
         - label:
-            "This issue affects my [Ory Cloud](https://www.ory.sh/) project."
+            "This issue affects my [Ory Network](https://www.ory.sh/) project."
         - label:
             "I have joined the [Ory Community Slack](https://slack.ory.sh)."
         - label:

.github/ISSUE_TEMPLATE/config.yml

@@ -1,3 +1,6 @@
+# AUTO-GENERATED, DO NOT EDIT!
+# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/ISSUE_TEMPLATE/config.yml
+
 blank_issues_enabled: false
 contact_links:
   - name: Ory Oathkeeper Forum

.github/auto_assign.yml

@@ -1,3 +1,6 @@
+# AUTO-GENERATED, DO NOT EDIT!
+# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/auto_assign.yml
+
 # Set to true to add reviewers to pull requests
 addReviewers: true
 

.github/config.yml

@@ -1,3 +1,6 @@
+# AUTO-GENERATED, DO NOT EDIT!
+# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/config.yml
+
 todo:
   keyword: "@todo"
   label: todo

.github/pull_request_template.md

@@ -2,7 +2,7 @@
 Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request.
 
 This text will be included in the changelog. If applicable, include links to documentation or pieces of code.
-If your change includes breaking changes please add a codeblock documenting the breaking change:
+If your change includes breaking changes please add a code block documenting the breaking change:
 
 ```
 BREAKING CHANGES: This patch changes the behavior of configuration item `foo` to do bar. To keep the existing
@@ -17,13 +17,13 @@ If this pull request
 
 1. is a fix for a known bug, link the issue where the bug was reported in the format of `#1234`;
 2. is a fix for a previously unknown bug, explain the bug and how to reproduce it in this pull request;
-2. implements a new feature, link the issue containing the design document in the format of `#1234`;
-3. improves the documentation, no issue reference is required.
+3. implements a new feature, link the issue containing the design document in the format of `#1234`;
+4. improves the documentation, no issue reference is required.
 
 Pull requests introducing new features, which do not have a design document linked are more likely to be rejected and take on average 2-8 weeks longer to
 get merged.
 
-You can discuss changes with maintainers either in the Github Discusssions in this repository or
+You can discuss changes with maintainers either in the Github Discussions in this repository or
 join the [Ory Chat](https://www.ory.sh/chat).
 -->
 
@@ -44,8 +44,8 @@ If you're unsure about any of them, don't hesitate to ask. We're here to help!
       [contributing code guidelines](../blob/master/CONTRIBUTING.md#contributing-code).
 - [ ] I have read the [security policy](../security/policy).
 - [ ] I confirm that this pull request does not address a security
-      vulnerability. If this pull request addresses a security. vulnerability, I
-      confirm that I got green light (please contact
+      vulnerability. If this pull request addresses a security vulnerability, I
+      confirm that I got the approval (please contact
       [security@ory.sh](mailto:security@ory.sh)) from the maintainers to push
       the changes.
 - [ ] I have added tests that prove my fix is effective or that my feature

.github/workflows/ci.yml

@@ -1,4 +1,4 @@
-name: CI Tasks for Ory Oathkeeper
+name: CI
 on:
   push:
     branches:
@@ -25,31 +25,29 @@ jobs:
         id: sdk-generate
 
   validate:
-    runs-on: ubuntu-latest
     name: Run tests and lints
+    runs-on: ubuntu-latest
     needs:
       - sdk-generate
     steps:
       - uses: ory/ci/checkout@master
-      - uses: actions/cache@v2
+      - uses: actions/cache@v3
         with:
-          path: |
-            internal/httpclient
+          path: internal/httpclient
           key: ${{ needs.sdk-generate.outputs.sdk-cache-key }}
       - uses: actions/setup-go@v2
         with:
-          go-version: ^1.17
+          go-version: 1.19
       - run: go list -json > go.list
       - name: Run nancy
         uses: sonatype-nexus-community/nancy-github-action@v1.0.2
-      - name: Run prettier
-        uses: ory/ci/prettier@master
       - name: Run golangci-lint
         uses: golangci/golangci-lint-action@v2
         env:
           GOGC: 100
         with:
           args: --timeout 10m0s
+          version: v1.47.3
           skip-go-installation: true
           skip-pkg-cache: true
       - name: Run go-acc (tests)
@@ -60,22 +58,6 @@ jobs:
         run: |
           bash <(curl -s https://codecov.io/bash)
 
-  setup-tests:
-    runs-on: ubuntu-latest
-    name: Setup tests
-    steps:
-      - uses: ory/ci/checkout@master
-      - uses: actions/setup-go@v2
-        with:
-          go-version: "^1.17"
-      - run: make install
-      - uses: actions/cache@v2
-        with:
-          path: ~/go/bin/oathkeeper
-          key: oathkeeper-${{ hashFiles('~/go/bin/oathkeeper') }}
-          restore-keys: |
-            oathkeeper-
-
   test:
     runs-on: ubuntu-latest
     name: Run tests
@@ -84,17 +66,19 @@ jobs:
         name: ["reload", "e2e", "forwarded-header"]
     needs:
       - sdk-generate
-      - setup-tests
     steps:
       - uses: ory/ci/checkout@master
       - uses: actions/setup-go@v2
         with:
-          go-version: "^1.17"
+          go-version: "1.19"
       - uses: actions/cache@v2
         with:
           path: ~/go/bin/oathkeeper
           key: oathkeeper-${{ hashFiles('~/go/bin/oathkeeper') }}
-      - run: ./test/${{ matrix.name }}/run.sh
+      - run: |
+          make install
+          go version -m $(which oathkeeper) | grep "\w*build"
+          ./test/${{ matrix.name }}/run.sh
 
   docs-cli:
     runs-on: ubuntu-latest
@@ -131,6 +115,7 @@ jobs:
       - uses: ory/ci/sdk/release@master
         with:
           token: ${{ secrets.ORY_BOT_PAT }}
+          swag-spec-location: spec/swagger.json
 
   release:
     name: Generate release
@@ -158,7 +143,7 @@ jobs:
     steps:
       - uses: ory/ci/releaser/render-version-schema@master
         with:
-          schema-path: spec/config.json
+          schema-path: .schema/config.schema.json
           token: ${{ secrets.ORY_BOT_PAT }}
 
   newsletter-draft:

.github/workflows/closed_references.yml

@@ -1,3 +1,6 @@
+# AUTO-GENERATED, DO NOT EDIT!
+# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/workflows/closed_references.yml
+
 name: Closed Reference Notifier
 
 on:

.github/workflows/conventional_commits.yml

@@ -0,0 +1,59 @@
+# AUTO-GENERATED, DO NOT EDIT!
+# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/workflows/conventional_commits.yml
+
+name: Conventional commits
+
+# This GitHub CI Action enforces that pull request titles follow conventional commits.
+# More info at https://www.conventionalcommits.org.
+#
+# The Ory-wide defaults for commit titles and scopes are below.
+# Your repository can add/replace elements via a configuration file at the path below.
+# More info at https://github.com/ory/ci/blob/master/conventional_commit_config/README.md
+
+on:
+  pull_request_target:
+    types:
+      - edited
+      - opened
+      - ready_for_review
+      - reopened
+  # pull_request: # for debugging, uses config in local branch but supports only Pull Requests from this repo
+
+jobs:
+  main:
+    name: Validate PR title
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - id: config
+        uses: ory/ci/conventional_commit_config@master
+        with:
+          config_path: .github/conventional_commits.json
+          default_types: |
+            feat
+            fix
+            revert
+            docs
+            style
+            refactor
+            test
+            build
+            autogen
+            security
+            ci
+            chore
+          default_scopes: |
+            deps
+            docs
+          default_require_scope: false
+      - uses: amannn/action-semantic-pull-request@v4
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        with:
+          types: ${{ steps.config.outputs.types }}
+          scopes: ${{ steps.config.outputs.scopes }}
+          requireScope: ${{ steps.config.outputs.requireScope }}
+          subjectPattern: ^(?![A-Z]).+$
+          subjectPatternError: |
+            The subject should start with a lowercase letter, yours is uppercase:
+            "{subject}"