docs refactor ee (#2130)

* docs refactor ee

* Update docs/ce/self-host/deploy-docker.mdx

Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>

* Update docs/ce/features/rbac.mdx

Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>

* Update docs/ce/features/opa-policies.mdx

Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>

* fix features

---------

Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>

Author: motatoes

docs/ee/ai-summaries.mdx renamed to docs/ce/features/ai-summaries.mdx

@@ -0,0 +1,51 @@
+---
+title: "Drift Detection"
+---
+
+
+# Drift alerts via Slack
+
+## Create a separate workflow file for drift
+
+To run digger in drift detection mode, pass `mode: drift-detection` in the workflow file and configure the relevant crontab to run it with the frequency you want:
+
+```
+name: Digger Drift Detection
+
+on:
+  workflow_dispatch:
+  schedule: ## 12am daily.
+    - cron: '0 0 * * *'
+
+jobs:
+  detect-drift:
+    runs-on: ubuntu-latest
+    steps:
+    - name: digger drift detection
+      uses: diggerhq/digger@vLatest
+      with:
+        mode: drift-detection
+        setup-aws: true
+        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
+        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
+        aws-region: us-east-1
+        drift-detection-slack-notification-url: ${{ secrets.DRIFT_DETECTION_SLACK_NOTIFICATION }}
+      env:
+        GITHUB_CONTEXT: ${{ toJson(github) }}
+        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+```
+
+## Configure Slack notification URL
+
+Note the `DRIFT_DETECTION_SLACK_NOTIFICATION` env var that the workflow above is using. This should be set to a Slack Incoming Webhook URL.
+
+Follow the [official Slack guide](https://api.slack.com/messaging/webhooks) to get the Incoming Webhook URL; then add it as an Action secret named `DRIFT_DETECTION_SLACK_NOTIFICATION`
+
+
+# Drift alerts via Github Issues
+
+Coming soon to CE, here is an example of how to configure it: https://github.com/diggerhq/demo-ee-features/edit/main/.github/workflows/drift.yml.
+Digger supports drift detection and automatic creation of issues in your ticketing system, e.g. GitHub Issues:
+
+<img height="400" src="/images/drift-issues.png" />
+

docs/ee/buildkite.mdx renamed to docs/ce/features/buildkite.mdx

@@ -96,3 +96,13 @@ Your Gitlab should also trigger and also perform a plan. If successful the job w
 ![](/images/ee/gitlab-1.png)
 
 ![](/images/ee/gitlab-2.png)
+
+
+## Repo allowlist
+
+You can set `DIGGER_REPO_ALLOW_LIST` env variable on the server to define a whitelist of repositories allowed to trigger Digger workflows in Gitlab. This is needed because unlike GitHub, there's no concept of "apps" in Gitlab to allow granular control of per-repo access.
+
+```
+DIGGER_REPO_ALLOW_LIST=gitlab.com/diggerdev/digger-demo,gitlab.com/diggerdev/alsoallowed
+```
+

docs/ce/features/drift-detection.mdx

@@ -3,7 +3,7 @@ title: "Multi Tenant Github Connections"
 ---
 
 
-In CE version of digger during onboarding you can use a wizard to create [a github app](/ce/self-host/deploy-docker#create-github-app) and inject it using environment variables.
+In the main onboarding flow you can use a wizard to create [a github app](/ce/self-host/deploy-docker#create-github-app) and inject it using environment variables.
 In larger orgs there could be a requirement that there are multiple orgs representing department. The github app created is installable on a single org only unless it is published.
 For enterprise usecases publishing to github marketplace is not feasible. For this reason we introduced multi-tenant github app via connections. Not only does this allow multiple app
 connections per org but it also makes it fully ui-based and there is no need to set environment variables. The way it works is as follows:
@@ -25,7 +25,7 @@ openssl rand -base64 24
 
 In your backend you can visit /github/connections and it will show you a screen like below
 
-![](images/ee/multi-tenant-github.png)
+![](/images/ee/multi-tenant-github.png)
 
 Within this screen you can see your current connections and also create your connections to an org. Type in your github org in the
 text box and click on "set up github app" to follow the wizard for creation in your org. Ensure that the button on github side says "create in diggerhq"

docs/ee/fips-140.mdx renamed to docs/ce/features/fips-140.mdx

@@ -27,8 +27,20 @@ This way you can implement custom logic, for example allowing to apply a PR that
 
 In Digger there are 3 ways to use OPA policies:
 
-- via Management Repo (EE)
-- via (unofficial) Orchestrator API (CE)
-- inline via Conftest (CE)
+- via Management Repo
+- via (unofficial) Orchestrator API
+- inline via Conftest
 
-See [OPA policies](/ee/opa) for more detail
+
+## Management repository
+
+OPA policies can be stored in a dedicated repository ([example](https://github.com/diggerhq/mgmt-repo-one/tree/main/policies)) that is separate from repositories that it controls
+In this management repo, policies can be structured using 3 levels:
+
+- organisation level (applies to all repos and projects)
+- repo level (applies to all project within a specific repo; overrides org-level)
+- project level (applies only to specific project; overrides repo-level and org-level)
+
+## Inline policies via custom commands
+The most basic way to use OPA policies with Digger is via [custom commands](/ce/howto/using-opa-conftest) - you can have a script that downloads policies from your storage of choice, and then invoke Conftest CLI directly as a custom workflow step in Digger. This is also a free feature of Digger Community Edition.
+The most basic way use OPA policies with Digger is via [custom commands](/ce/howto/using-opa-conftest) - you can have a script that downloads policies from your storage of choice, and then invoke Conftest CLI directly as a custom workflow step in Digger. This is also a free feature of Digger Community Edition.

docs/ee/gitlab.mdx renamed to docs/ce/features/gitlab.mdx

@@ -2,13 +2,13 @@
 title: "RBAC"
 ---
 
-Digger Enterprise supports granular Role-based Access Contros at 3 levels:
+For simple usecases you can rely on [CODEOWNERS](/ce/howto/codeowners) in order to control what is achievable in the PR. OPA can be used in advanced scenarios to get more control. Digger supports granular Role-based Access Controls at 3 levels:
 
 - Organisation
 - Repository
 - Project
 
-You can set up RBAC in Digger by configuring an Access Policy at the appropriate level of your Management Repo. See [OPA Policies](/ee/opa) for more detail.
+You can set up RBAC in Digger by configuring an Access Policy at the appropriate level of your Management Repo. See [OPA Policies](/ce/features/opa-policies) for more detail.
 
 Every Access Policy is passed the following details about the attempted operation from GitHub:
 
@@ -18,4 +18,3 @@ Every Access Policy is passed the following details about the attempted operatio
 
 This way you can implement advanced workflows such as [policy overrides](https://github.com/diggerhq/demo-policy-overrides/pull/9) based on roles and granular permissions.
 
-[Book a demo](https://calendly.com/diggerdev/diggerdemo)

docs/ee/multi-github.mdx renamed to docs/ce/features/multi-github.mdx

@@ -3,7 +3,7 @@ title: "Running Remote Jobs"
 ---
 
 With dgctl command line you can run jobs in a remote CI environment and have the logs streamed to your terminal.
-These tasks follow the same RBAC rules specified in your [opa policies](/ee/opa). For example this command:
+These tasks follow the same RBAC rules specified in your [opa policies](/ce/features/opa-policies). For example this command:
 
 ```
 dgctl exec --project <project_name> --command "digger plan"

docs/ce/features/opa-policies.mdx

@@ -4,7 +4,7 @@ title: "Inline policies (conftest)"
 
 <Note>
   This is the most basic way to use OPA policies with Digger. For more advanced
-  use cases check out [OPA policies](/ee/opa)
+  use cases check out [OPA policies](/ce/features/opa-policies)
 </Note>
 
 You can configure Digger CLI to run Conftest ito check your Terraform plan output against Open Policy Agent policies.