diff --git a/action.yml b/action.yml index b8595db55..3cce4974b 100644 --- a/action.yml +++ b/action.yml @@ -106,7 +106,7 @@ inputs: required: false default: 'true' upload-plan-destination: - description: Destination to upload the plan to. azure, gcp, github and aws are currently supported. + description: Destination to upload the plan to. Azure, GCP, GitHub and aws are currently supported. required: false upload-plan-destination-s3-bucket: description: Name of the destination bucket for AWS S3. Should be provided if destination == aws diff --git a/docs/ce/azure-specific/azure.mdx b/docs/ce/azure-specific/azure.mdx index 1345b1226..bbde204f3 100644 --- a/docs/ce/azure-specific/azure.mdx +++ b/docs/ce/azure-specific/azure.mdx @@ -14,7 +14,7 @@ Click "Go to Resource"; go to Access keys (on the lefthand side) Click "show" on the connection string. Copy and save it securely; it will be needed later in this guide. -## 2\. Add Azure keys to Github Actions Secrets +## 2\. Add Azure keys to GitHub Actions Secrets ### In Azure @@ -32,7 +32,7 @@ Go to Certificates and Secrets. Click New Client Secret. Give it a name; click A Go to **subscription** in the portal and select your subscription ID, select **Access Control (IAM)** and **Add** the **Role assignment**, **Contributor** to your Service Principal. Take note of your Subscription ID value -### In Github +### In GitHub - Go to Settings → Secrets and Variables diff --git a/docs/ce/features/opa-policies.mdx b/docs/ce/features/opa-policies.mdx index a7997e374..705c1c11e 100644 --- a/docs/ce/features/opa-policies.mdx +++ b/docs/ce/features/opa-policies.mdx @@ -17,7 +17,7 @@ With plan policies you can check `terraform plan` output for compliance with you With access policies you can control which Digger operations are allowed at any given time based on various inputs. Access policy is checked before every plan and apply and is passed the following data: -- user id (from github) +- user id (from GitHub) - plan policy violations, if any - list of users who approved the PR diff --git a/docs/ce/features/plan-preview.mdx b/docs/ce/features/plan-preview.mdx index d5d2a152d..3006276c6 100644 --- a/docs/ce/features/plan-preview.mdx +++ b/docs/ce/features/plan-preview.mdx @@ -17,4 +17,4 @@ You can also re-plan by commenting `digger plan` (see [CommentOps](/features/com * By performing locks on pull request we guarantee that the plan preview on the pull request is not stale. i.e. the infrastructure was not touched by another subsequent change -* Code in github: [https://github.com/diggerhq/digger/blob/5815775095d7380281c71c7c3aa63ca1b374365f/pkg/digger/digger.go#L228](https://github.com/diggerhq/digger/blob/5815775095d7380281c71c7c3aa63ca1b374365f/pkg/digger/digger.go#L228) +* Code in GitHub: [https://github.com/diggerhq/digger/blob/5815775095d7380281c71c7c3aa63ca1b374365f/pkg/digger/digger.go#L228](https://github.com/diggerhq/digger/blob/5815775095d7380281c71c7c3aa63ca1b374365f/pkg/digger/digger.go#L228) diff --git a/docs/ce/features/private-runners.mdx b/docs/ce/features/private-runners.mdx index 1d18753fc..ffe7168a1 100644 --- a/docs/ce/features/private-runners.mdx +++ b/docs/ce/features/private-runners.mdx @@ -4,7 +4,7 @@ title: "Private Runners" In many situations you wish to run digger with private runners. For example if you are provisioning resources in a private k8s cluster in this case you will not be able to use cloud runners. -While digger does not natively support k8s agents it is very easy to do it indirectly using github actions runners. +While Digger does not natively support k8s agents, it is easy to achieve this indirectly with GitHub Actions runners. In the typical digger flow you are using a workflow that looks like this: ``` @@ -16,8 +16,8 @@ jobs: runs-on: ubuntu-latest ``` -With github specifically there is good support for [self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners) -which means that you can create agents for github actions in your private infrastructure's VPC and github will then run the jobs there. +GitHub provides first-class support for [self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners) +which means that you can create agents for GitHub actions in your private infrastructure's VPC and GitHub will then run the jobs there. The easiest way to achieve self-hosted runners is by running the agent in something like an EC2 instance. Alternatively if you already have a kubernetes cluster you could opt for using the [Actions runner controller](which will provide you with actions right in your cluster). Once you have set up and configured your controllers diff --git a/docs/ce/gcp/federated-oidc-access.mdx b/docs/ce/gcp/federated-oidc-access.mdx index 617592763..37b9bde4b 100644 --- a/docs/ce/gcp/federated-oidc-access.mdx +++ b/docs/ce/gcp/federated-oidc-access.mdx @@ -15,7 +15,7 @@ gcloud iam workload-identity-pools create github-wif-pool --location="global" -- ## 2\. Create a Workload Identity Provider -A Workload Identity Provider links an external identity like Github with your Google Cloud account. This lets IAM use tokens from external providers to authorize access to Google Cloud resources. +A Workload Identity Provider links an external identity like GitHub with your Google Cloud account. This lets IAM use tokens from external providers to authorize access to Google Cloud resources. ``` gcloud iam workload-identity-pools providers create-oidc githubwif \ @@ -27,7 +27,7 @@ gcloud iam workload-identity-pools providers create-oidc githubwif \ ## 3\. Create a Service Account and bind policies -A service account with relevant permissions will be impersonated by WIF. This allows Github action to impersonate the service account and get a token. +A service account with relevant permissions will be impersonated by WIF. This allows GitHub action to impersonate the service account and get a token. ``` gcloud iam service-accounts create test-wif \ @@ -43,7 +43,7 @@ gcloud iam service-accounts add-iam-policy-binding test-wif@.iam.gserviceaccount --member="principalSet://iam.googleapis.com/projects//locations/global/workloadIdentityPools/github-wif-pool/attribute.repository/PradeepSingh1988/gcp-wif" ``` -## 4\. Add secrets to Github +## 4\. Add secrets to GitHub Create 2 secrets in your Action Secrets with the following names: diff --git a/docs/ce/gcp/setting-up-gcp-+-gh-actions.mdx b/docs/ce/gcp/setting-up-gcp-+-gh-actions.mdx index 85cd7f4ae..1695acb7a 100644 --- a/docs/ce/gcp/setting-up-gcp-+-gh-actions.mdx +++ b/docs/ce/gcp/setting-up-gcp-+-gh-actions.mdx @@ -19,7 +19,7 @@ Let's create our first pull request with a change and see this in action: ![](images/configuration/2.webp) -4. Add environment variables into your Github Action Secrets (cloud keys are a requirement since digger needs to connect to your account for coordinating locks). Use[ this guide](https://developers.google.com/workspace/guides/create-credentials) to get the value for it: +4. Add environment variables into your GitHub Action Secrets (cloud keys are a requirement since digger needs to connect to your account for coordinating locks). Use[ this guide](https://developers.google.com/workspace/guides/create-credentials) to get the value for it: ![](/images/gcp/1.png) diff --git a/docs/ce/getting-started/github-actions-+-aws.mdx b/docs/ce/getting-started/github-actions-+-aws.mdx index 081f4c24c..01414a040 100644 --- a/docs/ce/getting-started/github-actions-+-aws.mdx +++ b/docs/ce/getting-started/github-actions-+-aws.mdx @@ -1,8 +1,8 @@ --- -title: "Github Actions + AWS" +title: "GitHub Actions + AWS" --- -In this tutorial, you will set up Digger to automate terraform pull requests using Github Actions and AWS +In this tutorial, you will set up Digger to automate terraform pull requests using GitHub Actions and AWS # Prerequisites @@ -34,7 +34,7 @@ projects: dir: prod ``` -# Create Github Actions workflow file +# Create GitHub Actions workflow file Place it at `.github/workflows/digger_workflow.yml` (name is important!) diff --git a/docs/ce/getting-started/github-actions-and-gcp.mdx b/docs/ce/getting-started/github-actions-and-gcp.mdx index 7581b99f8..3342164a5 100644 --- a/docs/ce/getting-started/github-actions-and-gcp.mdx +++ b/docs/ce/getting-started/github-actions-and-gcp.mdx @@ -1,8 +1,8 @@ --- -title: "Github Actions + GCP" +title: "GitHub Actions + GCP" --- -In this tutorial, you will set up Digger to automate terraform pull requests using Github Actions and GCP. +In this tutorial, you will set up Digger to automate terraform pull requests using GitHub Actions and GCP. # Prerequisites @@ -33,7 +33,7 @@ projects: dir: prod ``` -# Create Github Actions workflow file +# Create GitHub Actions workflow file Place it at `.github/workflows/digger_workflow.yml` (name is important!) @@ -87,7 +87,7 @@ jobs: This file defines a workflow with 5 steps: -- Checkout repository using Github's official [Checkout action](https://github.com/actions/checkout) +- Checkout repository using GitHub's official [Checkout action](https://github.com/actions/checkout) - Authenticate into GCP using Google's official [Auth action](https://github.com/google-github-actions/auth). Note the `create_credentials_file: true` option; without it, subsequent steps that rely [Application Default Credentials](https://cloud.google.com/docs/authentication/provide-credentials-adc) will not work. - Set up Google Cloud SDK for use in the subsequent steps via Google's official [Setup-gcloud action](https://github.com/google-github-actions/setup-gcloud) - Verify that GCP is configured correctly by running `gcloud info` diff --git a/docs/ce/getting-started/gitlab-pipelines-+-aws.mdx b/docs/ce/getting-started/gitlab-pipelines-+-aws.mdx index ff3d087c1..ca00ac0ff 100644 --- a/docs/ce/getting-started/gitlab-pipelines-+-aws.mdx +++ b/docs/ce/getting-started/gitlab-pipelines-+-aws.mdx @@ -11,13 +11,13 @@ title: "GitLab Pipelines + AWS" ### Configuring and Deploying AWS Lambda: Step-by-Step Guide -1. Fork and clone this repo: [https://github.com/diggerhq/gitlab-webhook-lambda](https://github.com/diggerhq/gitlab-webhook-lambda). +1. Fork and clone this repo: [https://github.com/diggerhq/GitLab-webhook-lambda](https://github.com/diggerhq/GitLab-webhook-lambda). 2. If necessary, update the `serverless.yml` file in the cloned repository. This file contains configuration settings for the Lambda function and can be customized to suit your requirements. -3. Save the `GITLAB_TOKEN`to the SSM (Systems Manager) parameter store. You can choose any path for storing the token, but ensure that the `serverless.yml` file is updated accordingly if you deviate from the default path. For example, save the `GITLAB_TOKEN`to `ssm:/gitlab-dev-webhook-handler/dev/GITLAB_TOKEN`. +3. Save the `GITLAB_TOKEN`to the SSM (Systems Manager) parameter store. You can choose any path for storing the token, but ensure that the `serverless.yml` file is updated accordingly if you deviate from the default path. For example, save the `GITLAB_TOKEN`to `ssm:/GitLab-dev-webhook-handler/dev/GITLAB_TOKEN`. -4. Do the same for SECRET\_TOKEN, update serverless.yml if needed and save token value to ssm parameter (for example `ssm:/gitlab-dev-webhook-handler/dev/SECRET_TOKEN`) +4. Do the same for SECRET\_TOKEN, update serverless.yml if needed and save token value to ssm parameter (for example `ssm:/GitLab-dev-webhook-handler/dev/SECRET_TOKEN`) 5. Make sure that your AWS credentials are properly configured in the command-line interface (CLI). This ensures that you have the necessary permissions to deploy the Lambda function. diff --git a/docs/ce/howto/apply-requirements.mdx b/docs/ce/howto/apply-requirements.mdx index 3f3deef85..18d39fceb 100644 --- a/docs/ce/howto/apply-requirements.mdx +++ b/docs/ce/howto/apply-requirements.mdx @@ -10,8 +10,8 @@ You can use mergeability requirements together with Status Checks to achieve the Digger will not apply if the pull request is not in a “mergeable” state as specified by GitHub api. This means that if you have a separate status check and you have this check as “required” by branch protection rules then an attempt of digger apply will not go ahead. Note: there is a [known issue](https://github.com/diggerhq/digger/issues/1180) that would - cause the "mergability" check to conflict if you set the digger/apply check as required on github. We are working on a fix and in the meantime you have an option to turn off the mergability check if you want to have this digger/apply check as required. You can turn it off in the workflow configuration - by setting the `skip_merge_check` flag as follows (we have to set the other configurations since they are currently required): +cause the "mergeability" check to conflict if you set the digger/apply check as required on GitHub. We are working on a fix and, meanwhile, you can turn off the mergeability check. +You can turn it off in the workflow configuration by setting the `skip_merge_check` flag as follows (we have to set the other configurations since they are currently required): ``` projects: diff --git a/docs/ce/howto/auto-merge.mdx b/docs/ce/howto/auto-merge.mdx index 03aad06bb..cf8123011 100644 --- a/docs/ce/howto/auto-merge.mdx +++ b/docs/ce/howto/auto-merge.mdx @@ -11,10 +11,10 @@ projects: - name: production dir: prod auto_merge: true -auto_merge_strategy: "squash" # optional, only supported on github +auto_merge_strategy: "squash" # optional, only supported on GitHub ``` -If you are using github VCS you can also specify +If you are using GitHub VCS you can also specify `auto_merge_strategy` to define the type of strategy. Possible values are: - squash: for squash merge diff --git a/docs/ce/howto/generate-projects.mdx b/docs/ce/howto/generate-projects.mdx index 5bb22a3a0..46a7ed20f 100644 --- a/docs/ce/howto/generate-projects.mdx +++ b/docs/ce/howto/generate-projects.mdx @@ -108,7 +108,7 @@ Here is a curl request for it as an example" Where repo_full_name is just a path to the repo branch is the branch you want to cache from (always this would be your default branch -installation_id is your github installation ID and can be fetched from your github app settings (the place where you installed the app from) +installation_id is your GitHub installation ID and can be fetched from your GitHub app settings (the place where you installed the app from) You should get back a response that the caching has been initiated and in the backend logs you will see logs about cloning. You should see an entry for that repo in the repos_cache table if things are successful. Now you can decide how often you want to refresh the cache and you can then set up a cron task to curl that endpoint for the periods that you want to refresh. diff --git a/docs/ce/howto/project-level-roles.mdx b/docs/ce/howto/project-level-roles.mdx index 586b403e0..d53287f2c 100644 --- a/docs/ce/howto/project-level-roles.mdx +++ b/docs/ce/howto/project-level-roles.mdx @@ -43,10 +43,10 @@ generate_projects: # Assume role with cognito identity -The github action JWT token includes alot of useful fields such as `ref`, `sha`, `runner_environment` etc. however it is +The GitHub action JWT token includes alot of useful fields such as `ref`, `sha`, `runner_environment` etc. however it is challenging to write an AWS trust policy to match for these fields since only `aud` and `sub` fields are supported. Using cognito identity it is possible to remap the fields into principal tags which allows them to be matched in the trust policy. More information -about this is in this article: https://catnekaise.github.io/github-actions-abac-aws/cognito-identity/. +about this is in this article: https://catnekaise.GitHub.io/GitHub-actions-abac-aws/cognito-identity/. If you wish to perform this mapping in digger you can specify an additional aws_cognito_oidc configuration as follows: diff --git a/docs/ce/howto/store-plans-in-a-bucket.mdx b/docs/ce/howto/store-plans-in-a-bucket.mdx index aaadd408f..92ea084dd 100644 --- a/docs/ce/howto/store-plans-in-a-bucket.mdx +++ b/docs/ce/howto/store-plans-in-a-bucket.mdx @@ -2,12 +2,11 @@ title: "Store plans in a Bucket" --- -### Github -Digger can use Github Artifacts to store `terraform plan` outputs. In order to enable it you can set the following argument in digger_workflow.yml: +### GitHub +Digger can use GitHub Artifacts to store `terraform plan` outputs. In order to enable it you can set the following argument in digger_workflow.yml: ``` upload-plan-destination: github -``` ### GCP You can also configure plan outputs to be uploaded to GCP Buckets instead. This is handy in case you want your plan outputs to stay within your organisation's approved storage providers for security or compliance reasons. diff --git a/docs/ce/howto/trigger-directly.mdx b/docs/ce/howto/trigger-directly.mdx index 7c4e0dca5..0af2a5a75 100644 --- a/docs/ce/howto/trigger-directly.mdx +++ b/docs/ce/howto/trigger-directly.mdx @@ -4,7 +4,7 @@ title: "Trigger workflow directly" By default Digger workflows are triggered by an orchestrator backend (Digger Cloud or self-hosted) that listens to events from GitHub and triggers jobs in Actions. Without an orchestrator backend it is not possible to start jobs in parallel, so all plans and applies have to run sequentially in one action job, which can be slow. Also without an orchestrator backend the action needs to start on every commit and every comment, even if there were no terraform changes; large monorepos this can get expensive. -But in some scenarios e.g. small projects that have no need for concurrency, it might be easier to just use a standalone action triggered directly from GitHub events. You can achieve that by specifying triggers at the top of the workflow: +But in some scenarios e.g. small projects that have no need for concurrency, it might be easier to just use a standalone action triggered directly from github.events. You can achieve that by specifying triggers at the top of the workflow: ``` name: Digger Pull Request Workflow diff --git a/docs/ce/reference/action-inputs.mdx b/docs/ce/reference/action-inputs.mdx index 22566d18f..88f64e899 100644 --- a/docs/ce/reference/action-inputs.mdx +++ b/docs/ce/reference/action-inputs.mdx @@ -84,7 +84,7 @@ inputs: required: false default: 'true' upload-plan-destination: - description: Destination to upload the plan to. azure, gcp, github and aws are currently supported. + description: Destination to upload the plan to. Azure, GCP, GitHub and aws are currently supported. required: false upload-plan-destination-s3-bucket: description: Name of the destination bucket for AWS S3. Should be provided if destination == aws diff --git a/docs/ce/reference/digger.yml.mdx b/docs/ce/reference/digger.yml.mdx index 814335466..9e691079a 100644 --- a/docs/ce/reference/digger.yml.mdx +++ b/docs/ce/reference/digger.yml.mdx @@ -102,7 +102,7 @@ workflows: |-----------------------------|---------------------------------------------------------------|----------|----------|----------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------| | telemetry | boolean | true | no | allows collecting anonymised usage and debugging data | | | auto_merge | boolean | false | no | automatically merge pull requests when all checks pass | | -| auto_merge_strategy | string | "squash" | no | The merge strategy to use while automerging, defaults to "squash". Possible values: 'squash', 'merge' (for merge commits) and 'rebase' | currently only github supported for this flag | +| auto_merge_strategy | string | "squash" | no | The merge strategy to use while automerging, defaults to "squash". Possible values: 'squash', 'merge' (for merge commits) and 'rebase' | currently only GitHub supported for this flag | | pr_locks | boolean | true | no | Enable PR-level locking | | | delete_prior_comments | boolean | false | no | Enables digger to delete previous comments to reduce noise in the PR | | | projects | array of [Projects](/ce/reference/digger.yml#project) | \[\] | no | list of projects to manage | | @@ -168,7 +168,7 @@ workflows: | Key | Type | Default | Required | Description | Notes | | ---------- | ------ | ------- | -------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | name | string | | yes | name of the environment variable | | -| value_from | string | | yes | name of the other environment variable to get the value from | this can be used for secrets. For example you set a secret from some secret manager (e.g. github secrets) as environment variable and the remap it to another variable. E.g. setting DEV_TF_ACCESS_KEY as a secret in github action, but then remap it into AWS_ACCESS_KEY during terraform apply command execution | +| value_from | string | | yes | name of the other environment variable to get the value from | this can be used for secrets. For example you set a secret from some secret manager (e.g. GitHub secrets) as environment variable and the remap it to another variable. E.g. setting DEV_TF_ACCESS_KEY as a secret in GitHub action, but then remap it into AWS_ACCESS_KEY during terraform apply command execution | | value | string | | yes | value of the environment variable | this value will have a preference over value_from field if both are set | ### RoleToAssume @@ -246,7 +246,7 @@ Workflow configuration describes how to react to CI events. It has 3 sections: A project in Digger corresponds to a directory containing Terraform code. Projects are treated as standalone independent entities with their own locks. Digger will not prevent you from running plan and apply in different projects simultaneously. -You can run plan / apply in a specified project by using the -p option in Github PR comment: +You can run plan / apply in a specified project by using the -p option in GitHub PR comment: ```bash digger apply -p my-second-app diff --git a/docs/ce/securing-digger/external-provider.mdx b/docs/ce/securing-digger/external-provider.mdx index 0bf6a477c..952955f7c 100644 --- a/docs/ce/securing-digger/external-provider.mdx +++ b/docs/ce/securing-digger/external-provider.mdx @@ -2,7 +2,7 @@ title: "External providers code execution" --- -Digger executes terraform in github actions within previlliged environments. Since terraform has the ability +Digger executes Terraform in GitHub Actions within privileged environments. Since terraform has the ability to execute arbitrary code based on data blocks or external providers this can lead to a user with malicious intent to expose the environment variables within the CI environment, potentially leaking cloud secrets. @@ -12,5 +12,5 @@ Currently we are exploring solutions to avoid this security threat. The first th not use long-lived credentials to connect to your cloud account. Instead rely on OIDC for short-lived credentials to minimise the exposure from this threat. Secondly its important to ensure that only trusted individuals are allowed to update the terraform code. We are also working on additional solutions to secure -against this threat. For more details and to engage in the discussion please take a look at this github issue: +against this threat. For more details and to engage in the discussion please see this GitHub issue: https://github.com/diggerhq/digger/issues/1530 diff --git a/docs/ce/securing-digger/spec-signing.mdx b/docs/ce/securing-digger/spec-signing.mdx index bf839f5e3..b2bd8d9a8 100644 --- a/docs/ce/securing-digger/spec-signing.mdx +++ b/docs/ce/securing-digger/spec-signing.mdx @@ -47,7 +47,7 @@ information about the context. Here is an example of a spec JSON: "backend_type": "backend", }, "vcs": { - "vcs_type": "github", + "vcs_type": "GitHub", "actor": "motatoes", "repo_owner": "diggerhq", "repo_name": "demo-opentofu", @@ -56,7 +56,7 @@ information about the context. Here is an example of a spec JSON: "policy_type": "http", }, "plan_storage": { - "storage_type": "github_artefact" + "storage_type": "GitHub_artefact" } } } diff --git a/docs/ce/self-host/deploy-binary.mdx b/docs/ce/self-host/deploy-binary.mdx index 41b20cd8b..565feae6e 100644 --- a/docs/ce/self-host/deploy-binary.mdx +++ b/docs/ce/self-host/deploy-binary.mdx @@ -11,7 +11,7 @@ This guide describes self-hosting the orchestrator backend as a binary aka "roll open source (Apache 2.0 license) ([repo on GitHub](https://github.com/diggerhq/digger)). You do not need a license or an account on Digger Cloud to self-host Digger CE. If you require - enterprise-grade features like Github Enterprise Server support, SSO / SAML, + enterprise-grade features like GitHub Enterprise Server support, SSO / SAML, multi-team / multi-org - [Talk to us](https://calendly.com/diggerdev/digger-open-source-terraform-cloud-alternativ-clone) @@ -36,7 +36,7 @@ git clone https://github.com/diggerhq/digger.git # Set initial environment variables ``` -GITHUB_ORG=your_github_org +GITHUB_ORG=your_GitHub_org HOSTNAME=your_public_digger_hostname BEARER_AUTH_TOKEN=$(openssl rand -base64 12) DATABASE_URL=postgres://..... @@ -62,9 +62,9 @@ Go to your_digger_hostname:3000/projects; you should see the dashboard. The setu # Create GitHub app -Go to your_digger_hostname:3000/github/setup and click the Setup button. Follow the instructions on GitHub to install the app to the repositories in your organisation. +Go to your_digger_hostname:3000/GitHub/setup and click the Setup button. Follow the instructions on GitHub to install the app to the repositories in your organisation. -After the setup is done, GitHub should redirect you to the summary page at your_digger_hostname:3000/github/exchange-code +After the setup is done, GitHub should redirect you to the summary page at your_digger_hostname:3000/GitHub/exchange-code Copy the values into the following environment variables and restart the service. @@ -80,7 +80,7 @@ GITHUB_WEBHOOK_SECRET= On the exchange-code page (see above) click the installation link at the top and select the repositories. -From here on it's the same steps as in the [Quickstart](/ce/getting-started/github-actions-+-aws): +From here on it's the same steps as in the [Quickstart](/ce/getting-started/GitHub-actions-+-aws): - Create digger.yml - Create workflow file diff --git a/docs/ce/self-host/deploy-docker-compose.mdx b/docs/ce/self-host/deploy-docker-compose.mdx index f636d6567..d5f4b0413 100644 --- a/docs/ce/self-host/deploy-docker-compose.mdx +++ b/docs/ce/self-host/deploy-docker-compose.mdx @@ -7,7 +7,7 @@ Digger has 2 main components: the CLI that runs within your CI and an orchestrat This guide describes self-hosting the orchestrator backend as a binary aka "roll your own". Self-hosting may come handy when using the cloud-based version of it is not an option (for example due to compliance requirements). More guides (docker, EC2, etc) are coming soon. -This guide is about self-hosting Digger Community Edition which is free and open source (Apache 2.0 license) ([repo on GitHub](https://github.com/diggerhq/digger)). You do not need a license or an account on Digger Cloud to self-host Digger CE. If you require enterprise-grade features like Github Enterprise Server support, SSO / SAML, multi-team / multi-org - [Talk to us](https://calendly.com/diggerdev/digger-open-source-terraform-cloud-alternativ-clone) +This guide is about self-hosting Digger Community Edition which is free and open source (Apache 2.0 license) ([repo on GitHub](https://github.com/diggerhq/digger)). You do not need a license or an account on Digger Cloud to self-host Digger CE. If you require enterprise-grade features like GitHub Enterprise Server support, SSO / SAML, multi-team / multi-org - [Talk to us](https://calendly.com/diggerdev/digger-open-source-terraform-cloud-alternativ-clone) # Prerequisites @@ -54,7 +54,7 @@ services: # Set initial environment variables ``` -GITHUB_ORG=your_github_org +GITHUB_ORG=your_GitHub_org HOSTNAME=your_public_digger_hostname BEARER_AUTH_TOKEN=$(openssl rand -base64 12) DATABASE_URL=postgres://postgres:root@postgres:5432/postgres?sslmode=disable @@ -73,9 +73,9 @@ You should now see initial database migrations and tables being created. Go to y # Create GitHub app -Go to your_digger_hostname:3000/github/setup and click the Setup button. Follow the instructions on GitHub to install the app to the repositories in your organisation. +Go to your_digger_hostname:3000/GitHub/setup and click the Setup button. Follow the instructions on GitHub to install the app to the repositories in your organisation. -After the setup is done, GitHub should redirect you to the summary page at your_digger_hostname:3000/github/exchange-code +After the setup is done, GitHub should redirect you to the summary page at your_digger_hostname:3000/GitHub/exchange-code Copy the values into the following environment variables and restart the service. @@ -91,7 +91,7 @@ GITHUB_WEBHOOK_SECRET= On the exchange-code page (see above) click the installation link at the top and select the repositories. -From here on it's the same steps as in the [Quickstart](/ce/getting-started/github-actions-+-aws): +From here on it's the same steps as in the [Quickstart](/ce/getting-started/GitHub-actions-+-aws): - Create digger.yml - Create workflow file - Create secrets diff --git a/docs/ce/self-host/deploy-docker.mdx b/docs/ce/self-host/deploy-docker.mdx index 360ac2d5b..5a596d076 100644 --- a/docs/ce/self-host/deploy-docker.mdx +++ b/docs/ce/self-host/deploy-docker.mdx @@ -7,7 +7,7 @@ Digger has 2 main components: the CLI that runs within your CI and an orchestrat This guide describes self-hosting the orchestrator backend as a binary aka "roll your own". Self-hosting may come handy when using the cloud-based version of it is not an option (for example due to compliance requirements). More guides (docker, EC2, etc) are coming soon. -This guide is about self-hosting Digger Community Edition which is free and open source (Apache 2.0 license) ([repo on GitHub](https://github.com/diggerhq/digger)). You do not need a license or an account on Digger Cloud to self-host Digger CE. If you require enterprise-grade features like Github Enterprise Server support, SSO / SAML, multi-team / multi-org - [Talk to us](https://calendly.com/diggerdev/digger-open-source-terraform-cloud-alternativ-clone) +This guide is about self-hosting Digger Community Edition which is free and open source (Apache 2.0 license) ([repo on GitHub](https://github.com/diggerhq/digger)). You do not need a license or an account on Digger Cloud to self-host Digger CE. If you require enterprise-grade features like GitHub Enterprise Server support, SSO / SAML, multi-team / multi-org - [Talk to us](https://calendly.com/diggerdev/digger-open-source-terraform-cloud-alternativ-clone) # Prerequisites @@ -17,7 +17,7 @@ Using Docker compose is the easiest way to try digger quickly on a machine. # Download the docker image: -You can fetch the docker image using the instructions on [github packages](https://github.com/diggerhq/digger/pkgs/container/digger_backend): +You can fetch the docker image using the instructions on [GitHub packages](https://github.com/diggerhq/digger/pkgs/container/digger_backend): ``` docker pull registry.digger.dev/diggerhq/digger_backend:latest @@ -26,7 +26,7 @@ docker pull registry.digger.dev/diggerhq/digger_backend:latest # Set initial environment variables ``` -GITHUB_ORG=your_github_org +GITHUB_ORG=your_GitHub_org HOSTNAME=your_public_digger_hostname BEARER_AUTH_TOKEN=$(openssl rand -base64 12) DATABASE_URL=postgres://postgres:PASSWORD@POSTGRESHOSTNAME:5432/postgres @@ -45,9 +45,9 @@ You should now see initial database migrations and tables being created. Go to y # Create GitHub app -Go to your_digger_hostname:3000/github/setup and click the Setup button. Follow the instructions on GitHub to install the app to the repositories in your organisation. +Go to your_digger_hostname:3000/GitHub/setup and click the Setup button. Follow the instructions on GitHub to install the app to the repositories in your organisation. -After the setup is done, GitHub should redirect you to the summary page at your_digger_hostname:3000/github/exchange-code +After the setup is done, GitHub should redirect you to the summary page at your_digger_hostname:3000/GitHub/exchange-code Copy the values into the following environment variables and restart the service. diff --git a/docs/ce/self-host/deploy-helm.mdx b/docs/ce/self-host/deploy-helm.mdx index f3dc2ee01..e3be40841 100644 --- a/docs/ce/self-host/deploy-helm.mdx +++ b/docs/ce/self-host/deploy-helm.mdx @@ -5,8 +5,8 @@ title: 'Digger Helm Chart' ## Installation steps -1. Install the `digger-backend` helm chart from https://diggerhq.github.io/helm-charts/, leaving empty all the data related to the GitHub App -2. Go to `your_digger_hostname/github/setup` to install and configure the GitHub App +1. Install the `digger-backend` helm chart from https://diggerhq.GitHub.io/helm-charts/, leaving empty all the data related to the GitHub App +2. Go to `your_digger_hostname/GitHub/setup` to install and configure the GitHub App 3. Configure in the helm values or in the external secret all the data related to the new GitHub app and upgrade the helm installation to reload the Digger application with the new configuration ## Configuration Details diff --git a/docs/ce/self-host/self-host-on-azure.mdx b/docs/ce/self-host/self-host-on-azure.mdx index 7c9a17ba7..18175788b 100644 --- a/docs/ce/self-host/self-host-on-azure.mdx +++ b/docs/ce/self-host/self-host-on-azure.mdx @@ -2,15 +2,15 @@ title: "Self Host on Azure" --- -This guide will show you how to set up digger orchestrator on azure and setup your github workflow to trigger workflow on azure\! This guide assumes that you are using github actions for CI. Lets get started +This guide will show you how to set up digger orchestrator on azure and setup your GitHub workflow to trigger workflow on azure\! This guide assumes that you are using GitHub actions for CI. Lets get started # Installing the orchestrator -The easiest way to install the orchestrator is via helmchart in kubernetes. The deployed service needs to be able to listen to webhooks from github for using github actions +The easiest way to install the orchestrator is via helmchart in kubernetes. The deployed service needs to be able to listen to webhooks from GitHub for using GitHub actions ## Install the helm chart -Install the `digger-backend` helm chart from [**https://diggerhq.github.io/helm-charts/**](https://diggerhq.github.io/helm-charts/**), leaving empty all the data related to the GitHub App. You can also use the postgres database defined within the helmchart or define your own. Here’s a good starter set for my-values.yml: +Install the `digger-backend` helm chart from [**https://diggerhq.GitHub.io/helm-charts/**](https://diggerhq.GitHub.io/helm-charts/**), leaving empty all the data related to the GitHub App. You can also use the postgres database defined within the helmchart or define your own. Here’s a good starter set for my-values.yml: ``` digger: @@ -32,13 +32,20 @@ digger: httpBasicAuthPassword: "abc123" bearerAuthToken: "salkfjadslkfj" # You should generate hostname: "" - githubOrg: "diggerhq" # replace with org for digger - githubAppID: "" - githubAppClientID: "" - githubAppClientSecret: "" - githubAppKeyFile: "" #base64 encoded file - githubWebhookSecret: "" - + secret: + useExistingSecret: false + existingSecretName: "" + + httpBasicAuthUsername: "admin" + httpBasicAuthPassword: "abc123" + bearerAuthToken: "salkfjadslkfj" + hostname: "" + githubOrg: "diggerhq" # replace with org for digger + githubAppID: "" + githubAppClientID: "" + githubAppClientSecret: "" + githubAppKeyFile: "" # base64 encoded file + githubWebhookSecret: "" postgres: enabled: true secret: @@ -48,7 +55,7 @@ postgres: you can save this file in a file like `mydigger.yml` and run the following helm commands to install it in your k8s cluster: ``` -$ helm repo add digger +$ helm repo add digger $ helm repo update $ helm install mydigger digger/digger-backend -f mydigger.yml ``` @@ -59,24 +66,24 @@ If all goes well you will see this fancy welcome screen when you visit the endpo ![Screenshot2025 05 26at19 00 55 Pn](/docs/images/Screenshot2025-05-26at19.00.55.png) -Now you can visit /github/setup endpoint and you will be greeted with this setup wizard for creation of a digger github app with the right settings +Now you can visit /GitHub/setup endpoint and you will be greeted with this setup wizard for creation of a digger GitHub app with the right settings ![Screenshot2025 05 26at19 00 33 Pn](/docs/images/Screenshot2025-05-26at19.00.33.png) ![Screenshot2025 05 26at19 00 38 Pn](/docs/images/Screenshot2025-05-26at19.00.38.png) -After successful installation you will see all the github credentials in the redirect including ID, webhook secret, private key and so on +After successful installation you will see all the GitHub credentials in the redirect including ID, webhook secret, private key and so on ![Screenshot2025 05 26at19 14 34 Pn](/docs/images/Screenshot2025-05-26at19.14.34.png) Now we need to update the values from mydigger.yml above for these secrets: ``` - githubAppID: "add" - githubAppClientID: "add" - githubAppClientSecret: "add" - githubAppKeyFile: "add" - githubWebhookSecret: "add" + GitHubAppID: "add" + GitHubAppClientID: "add" + GitHubAppClientSecret: "add" + GitHubAppKeyFile: "add" + GitHubWebhookSecret: "add" ``` Next is to update the helmchart: @@ -85,7 +92,7 @@ Next is to update the helmchart: $ helm upgrade mydigger digger/digger-backend -f digger.yml ``` -Now we can install the newly created github app into the org and if all goes well we should see a succesful installation (pick the test repo where you have terraform in)\! +Now we can install the newly created GitHub app into the org and if all goes well we should see a succesful installation (pick the test repo where you have terraform in)\! ![Screenshot2025 05 26at19 58 03 Pn](/docs/images/Screenshot2025-05-26at19.58.03.png) @@ -133,9 +140,9 @@ For GitHub Actions with OIDC (which is likely what you're setting up), you'll al - `AZURE_TENANT_ID` - `AZURE_SUBSCRIPTION_ID` -## Configure Github workflow: +## Configure GitHub workflow: -create this github workflow in your repository under `.github/workflow/digger_workflow.yml` +create this GitHub workflow in your repository under `.GitHub/workflow/digger_workflow.yml` ``` name: Digger Workflow diff --git a/docs/ee/buildkite.mdx b/docs/ee/buildkite.mdx index e1f0e5a38..f5216b962 100644 --- a/docs/ee/buildkite.mdx +++ b/docs/ee/buildkite.mdx @@ -3,7 +3,7 @@ title: "Buildkite CI backend" --- You can use digger with buildkite as a CI backend. Currently this is an EE feature only. -Github is the VCS which is supported with this flow. +GitHub is the VCS which is supported with this flow. ### Prerequisites: @@ -27,7 +27,7 @@ BUILDKITE_PIPELINE=my_digger_pipeline ``` Other than that if you follow the steps in the self hosting guide you should end up with the orchestrator up and running -along with a github app successfully installed. The repo you wish to try with digger should be installed onto the orchestrator. +along with a GitHub app successfully installed. The repo you wish to try with digger should be installed onto the orchestrator. ### Install digger cli in your buildkite agent @@ -73,5 +73,5 @@ buildkite should also trigger and also perform a plan ![](/images/buildkite/buildkite.png) -![](/images/buildkite/github_comment.png) +![](/images/buildkite/github.comment.png) diff --git a/docs/ee/drift-detection.mdx b/docs/ee/drift-detection.mdx index 33d25050b..05401bbbb 100644 --- a/docs/ee/drift-detection.mdx +++ b/docs/ee/drift-detection.mdx @@ -51,9 +51,9 @@ Note the `DRIFT_DETECTION_SLACK_NOTIFICATION` env var that the workflow above is 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` -## Gitlab +## GitLab -For using drift detection with gitlab, a similar workflow can be used: +For using drift detection with GitLab, a similar workflow can be used: ``` variables: diff --git a/docs/ee/ee-setup.mdx b/docs/ee/ee-setup.mdx index 86f83f6f5..aafec54de 100644 --- a/docs/ee/ee-setup.mdx +++ b/docs/ee/ee-setup.mdx @@ -12,13 +12,13 @@ Setting up the backend is the same as in CE so you can follow the relevant guide - Helm chart guide: https://docs.digger.dev/self-host/deploy-helm - Docker image guide: https://docs.digger.dev/self-host/deploy-docker -By the end of this you should have your orchestrator up and running internally, you will also have setup the internal github app for your org internally. +By the end of this you should have your orchestrator up and running internally, you will also have setup the internal GitHub app for your org internally. # Step 2: Setting up the POC Repo After you have the orchestrator up and running you will need a repo to test digger on. For using it with terragrunt you can rely on this example as a starting point: https://github.com/diggerhq/demo-terragrunt-parallel-ee feel free to fork it or clone and re-push it as an internal repo, or you can just copy the same structure, with digger.yml in the root of the repo as well as a workflow file `digger_workflow.yml` -Once you have the repo ready you need to install it to the image. So make sure to install the github app in your organisation, adding the POC repository to it. +Once you have the repo ready you need to install it to the image. So make sure to install the GitHub app in your organisation, adding the POC repository to it. In order to proceed with an example plan you will also need to set a secret called `DIGGER_LICENSE_KEY` and the value of the license key that has been provided above. diff --git a/docs/ee/fips-140.mdx b/docs/ee/fips-140.mdx index 4b7a0038a..873e85ab0 100644 --- a/docs/ee/fips-140.mdx +++ b/docs/ee/fips-140.mdx @@ -4,7 +4,7 @@ title: "FIPS 140 standard" You can use digger binary with FIPS140 standard. FIPS 140 (Federal Information Processing Standard Publication 140) is a U.S. government standard that specifies security requirements for cryptographic modules protecting sensitive information. -as of version v0.6.101 digger backend and cli are both compiled seperately with FIPS140 enabled. In order to enable it for github follow these steps: +As of version v0.6.101, the Digger backend and CLI are compiled separately with FIPS 140 enabled. To enable it for GitHub, follow these steps: - For the backend you need to ensure you use the right docker image: `_backend_ee_fips` during the pull - For the cli you need to add the following argument in addition to `ee: true` : @@ -16,4 +16,4 @@ as of version v0.6.101 digger backend and cli are both compiled seperately with fips: 'true' ``` -If you are using gitlab or other VCS then just ensure that you are downloading the fips enabled binary which is suffixed with '_fips' \ No newline at end of file +If you are using GitLab or another VCS, ensure that you download the FIPS-enabled binary, which is suffixed with `_fips`. diff --git a/docs/ee/gitlab-support.mdx b/docs/ee/gitlab-support.mdx index 168e4fa2e..e69c26806 100644 --- a/docs/ee/gitlab-support.mdx +++ b/docs/ee/gitlab-support.mdx @@ -1,16 +1,15 @@ --- -title: "Gitlab CI and Pipelines" +title: "GitLab CI and Pipelines" --- -You can use digger with gitlab as your VCS and gitlab pipelines as a CI backend. Currently this is an EE feature only. +You can use digger with GitLab as your VCS and GitLab pipelines as a CI backend. Currently this is an EE feature only. ### Prerequisites: - Having a valid digger EE license key. If you don't have a license key please [contact us](https://calendly.com/diggerdev/diggerdemo) to request an EE trial -- A gitlab account. -- a personal github access token. This can be created from user preferences > access tokens - +- A GitLab account. +- A personal GitLab access token. This can be created from User Preferences > Access Tokens ### Install the digger EE orchestrator: You need to install the digger EE orchestrator. The installation steps are the same as the steps in [self hosting docker](/self-host/deploy-docker) @@ -18,17 +17,17 @@ with some differences: - For the docker image you will need to use the ee image: https://github.com/diggerhq/digger/pkgs/container/digger_backend - You will need to include the license key environment variable to the backend and the cli: `DIGGER_LICENSE_KEY=xxxyyy` -- You can ignore all the steps regarding setting up Github app and all GITHUB_** environment variables -- For gitlab CI configuration you need to specify the following environment variables: +- You can ignore all the steps regarding setting up GitHub app and all GITHUB_** environment variables +- For GitLab CI configuration you need to specify the following environment variables: ``` DIGGER_CI_BACKEND=gitlab_pipelines DIGGER_GITLAB_WEBHOOK_SECRET=abc123 -DIGGER_GITLAB_ACCESS_TOKEN=glpat-xxxxyyyyyzzzzz # (this is your gitlab access token from prerequisite step) +DIGGER_GITLAB_ACCESS_TOKEN=glpat-xxxxyyyyyzzzzz # (this is your GitLab access token from prerequisite step) ``` Other than that if you follow the steps in the self hosting guide you should end up with the orchestrator up and running -along with a github app successfully installed. The repo you wish to try with digger should be installed onto the orchestrator. +with the GitLab webhook configured for your test repository and the orchestrator running. ### Prepare your repo with a digger.yml @@ -42,16 +41,16 @@ projects: dir: dev/ ``` -### Setting up gitlab webhooks +### Setting up GitLab webhooks In the repo where you are interested to integrate with digger you need to set up a webhook pointing to your digger hostname. Go to Settings > Webhooks and add digger host name. Set the secret token as "abc123" (same as `DIGGER_GITLAB_WEBHOOK_SECRET`) above. make sure that "Comments" and "Merge request events" are selected for Trigger events. Finally you can save. -### Create digger pipeline in your gitlab repo +### Create digger pipeline in your GitLab repo -To create a gitlab pipeline you can use a .gitlab-ci.yml file in the root of your file. In this you need to +To create a GitLab pipeline you can use a .gitlab-ci.yml file in the root of your file. In this you need to create a script which downloads digger binary and invokes it, the purpose here is to have this pipeline triggered by digger externally. Here is an example of such file: @@ -86,7 +85,7 @@ digger_action: # - git clone https://github.com/diggerhq/digger.git # - cd digger/cli # - pwd - # - git checkout feat/gitlab-support2 + # - git checkout feat/GitLab-support2 # - GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o digger ./cmd/digger # - PATH=$PATH:$(pwd) # - cd ../../ @@ -102,15 +101,15 @@ all you need to set up and try digger! In order to test your setup try to create a pull request in your repo. After you Comment "digger plan" You should see in the backend logs that a webhook event was received and an initial comment should be triggered in your pull request. Your -gitlab should also trigger and also perform a plan. If successful the job will comment back the plan as follows: +GitLab should also trigger and also perform a plan. If successful the job will comment back the plan as follows: -![](/images/gitlab/gitlab-plan.png) +![](/images/GitLab/GitLab-plan.png) -![](/images/gitlab/gitlab-apply.png) +![](/images/GitLab/GitLab-apply.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. +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 diff --git a/docs/ee/gitlab.mdx b/docs/ee/gitlab.mdx index 233197dcb..cbc4fd315 100644 --- a/docs/ee/gitlab.mdx +++ b/docs/ee/gitlab.mdx @@ -1,15 +1,15 @@ --- -title: "Gitlab Pipelines" +title: "GitLab Pipelines" --- -You can use Digger with Gitlab as your VCS and Gitlab pipelines as a CI backend. Currently this is an EE feature only. +You can use Digger with GitLab as your VCS and GitLab pipelines as a CI backend. Currently this is an EE feature only. ### Prerequisites: - Having a valid Digger EE license key. This needs to be provided by us, please [contact us](https://digger.dev/pricing) to request it -- A Gitlab account. -- A personal Gitlab access token. This can be created from user preferences > access tokens +- A GitLab account. +- A personal GitLab access token. This can be created from user preferences > access tokens ### Install the digger EE orchestrator: @@ -17,17 +17,17 @@ You need to install the digger EE orchestrator. The installation steps are the s - For the docker image you will need to use the ee image: https://github.com/diggerhq/digger/pkgs/container/digger_backend_ee **(latest version, v0.6.5 as of this guide)** - You will need to include the license key environment variable to the backend and the cli: **`DIGGER_LICENSE_KEY=xxxyyy`** -- You can ignore all the steps regarding setting up Github app and all GITHUB_** environment variables -- For gitlab CI configuration you need to specify the following environment variables: +- You can ignore all the steps regarding setting up GitHub app and all GITHUB_** environment variables +- For GitLab CI configuration you need to specify the following environment variables: ```jsx DIGGER_CI_BACKEND=gitlab_pipelines DIGGER_GITLAB_WEBHOOK_SECRET=abc123 -DIGGER_GITLAB_ACCESS_TOKEN=glpat-xxxxyyyyyzzzzz # (this is your gitlab access token from prerequisite step)` +DIGGER_GITLAB_ACCESS_TOKEN=glpat-xxxxyyyyyzzzzz # (this is your GitLab access token from prerequisite step)` DIGGER_GITLAB_BASE_URL=https://git.mydomain.com/api/v4 ``` -Other than that if you follow the steps in the self hosting guide you should end up with the orchestrator up and running along with a webhook set for your gitlab POC repo. +Other than that if you follow the steps in the self hosting guide you should end up with the orchestrator up and running along with a webhook set for your GitLab POC repo. ### Prepare your repo with a digger.yml @@ -39,14 +39,13 @@ projects: dir: dev/ ``` -**Setting up Gitlab webhooks** +**Setting up GitLab webhooks** In the repo where you are interested to integrate with digger you need to set up a webhook pointing to your digger hostname. Go to Settings > Webhooks and add digger host name. Set the secret token as “abc123” (same as **`DIGGER_GITLAB_WEBHOOK_SECRET`**) above. make sure that “Comments” and “Merge request events” are selected for Trigger events. Finally you can save. -### Create digger pipeline in your gitlab repo - -To create a Gitlab pipeline you can use a .gitlab-ci.yml file in the root of your file. In this you need to create a script which downloads Digger binary and invokes it, the purpose here is to have this pipeline triggered by Digger externally. Here is an example of such file: +### Create digger pipeline in your GitLab repo +To create a GitLab pipeline you can use a .gitlab-ci.yml file in the root of your repository. In this you need to create a script which downloads Digger binary and invokes it, the purpose here is to have this pipeline triggered by Digger externally. Here is an example of such file: ```jsx variables: @@ -91,8 +90,8 @@ This will instruct digger to run the “spec” which is composed and sent from In order to test your setup try to create a pull request in your repo. After you Comment “digger plan” You should see in the backend logs that a webhook event was received and an initial comment should be triggered in your pull request. -Your Gitlab should also trigger and also perform a plan. If successful the job will comment back the plan as follows: +Your GitLab should also trigger and also perform a plan. If successful the job will comment back the plan as follows: -![](/images/ee/gitlab-1.png) +![](/images/ee/GitLab-1.png) -![](/images/ee/gitlab-2.png) +![](/images/ee/GitLab-2.png) diff --git a/docs/ee/multi-github.mdx b/docs/ee/multi-github.mdx index cbc922bec..274407494 100644 --- a/docs/ee/multi-github.mdx +++ b/docs/ee/multi-github.mdx @@ -1,18 +1,18 @@ --- -title: "Multi Tenant Github Connections" +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 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 +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 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: ### Prerequisite As a prerequisite for this step you need to have already set the environment variable for `DIGGER_ENCRYPTION_SECRET` -which is a 32 character string used for encrypting the github values. You can generate one in openssl as follows: +which is a 32 character string used for encrypting the GitHub values. You can generate one in openssl as follows: The second important point is that you should not have any GITHUB_XXXX environment variables set (example GITHUB_CLIENT_ID) since digger will look for env variables first before it searches for connection matches from DB. @@ -23,14 +23,14 @@ openssl rand -base64 24 ### how to set up multi org connections: -In your backend you can visit /github/connections and it will show you a screen like below +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" +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" so it is installed in the right organisation. Upon success you will be redirected back to the same page and you should see that connection in the table You can click on the link to install that connection from the table **Important**: its important to install using the link in the table since an additional "state" parameter is passed containing app ID metadata in order to -verify the app on callback. If you attempt to install the created app from github directly it will lead to an error. \ No newline at end of file +verify the app on callback. If you attempt to install the created app from GitHub directly it will lead to an error. \ No newline at end of file diff --git a/docs/mint.json b/docs/mint.json index 1cf948b63..35dc52982 100644 --- a/docs/mint.json +++ b/docs/mint.json @@ -15,7 +15,7 @@ } }, "topbarCtaButton": { - "type": "github", + "type": "GitHub", "url": "https://github.com/diggerhq/digger" }, "anchors": [ diff --git a/docs/readme/feedback.mdx b/docs/readme/feedback.mdx index 9cbb08763..e3423ad8e 100644 --- a/docs/readme/feedback.mdx +++ b/docs/readme/feedback.mdx @@ -6,7 +6,7 @@ We are always looking at feedback and suggestions from the community. If somethi please tell us. We are always keen on thoughts/feedback. -Head over to [Github](https://github.com/diggerhq/digger/blob/develop/docs/readme/feedback.mdx) and raise a PR to add your feedback below (Optionally link to a github issue if you find it is relevant to your feedback) +Head over to [GitHub](https://github.com/diggerhq/digger/blob/develop/docs/readme/feedback.mdx) and raise a PR to add your feedback below (Optionally link to a GitHub issue if you find it is relevant to your feedback) ## To-do list (Issues, feedback and feature requests) diff --git a/docs/readme/introduction.mdx b/docs/readme/introduction.mdx index fd924cc6e..b0292ad80 100644 --- a/docs/readme/introduction.mdx +++ b/docs/readme/introduction.mdx @@ -29,6 +29,6 @@ Read more about differences with Atlantis in our [blog post](https://medium.com/ ## Support for other CI's -We are currently designing Digger to be Multi-CI, so that in addition to GitHub Actions, you can run Terraform/OpenTofu within other CI's such as Gitlab CI, Azure DevOps, Bitbucket, TeamCity, Circle CI and Jenkins, while still having the option to orchestrate jobs using Digger's [Orchestrator Backend](https://docs.digger.dev/self-host/deploy-docker). +We are currently designing Digger to be Multi-CI, so that in addition to GitHub Actions, you can run Terraform/OpenTofu within other CI's such as GitLab CI, Azure DevOps, Bitbucket, TeamCity, Circle CI and Jenkins, while still having the option to orchestrate jobs using Digger's [Orchestrator Backend](https://docs.digger.dev/self-host/deploy-docker). Read more in this [blog](https://blog.digger.dev/how-we-are-designing-digger-to-support-multiple-ci-systems/), and please share your requirement on [Slack](https://bit.ly/diggercommunity) if you require support for other CI's. Your feedback/insight would help us a lot as this feature is in active development. \ No newline at end of file diff --git a/docs/readme/pricing.mdx b/docs/readme/pricing.mdx index 65db50001..d16deb7c8 100644 --- a/docs/readme/pricing.mdx +++ b/docs/readme/pricing.mdx @@ -23,7 +23,7 @@ title: "Pricing" | Drift Detection                  | ❌| ✅ | | RBAC via OPA                     | ❌| ✅ | | Org-level policies (OPA)         | ❌| ✅ | -| Private VCS Support - GitHub, Gitlab & Bitbucket        | ❌ | ✅ | +| Private VCS Support - GitHub, GitLab & Bitbucket        | ❌ | ✅ | | Audit Log Retention              | ❌ | ✅ | | Compliance Frameworks            | ❌ | ✅ | | 99.99% SLA                       | ❌ | ✅ | @@ -39,11 +39,11 @@ Digger currently has no paid middle tier. You could use the self managed free to Digger enterprise is for customers requiring access to the dashboard, SSO via SAML 2.0, Drift Detection, RBAC and Private VCS support. -**Which parts of Digger is Open Source?** +**Which parts of Digger are Open Source?** -All of Digger is open source, even the enterprise edition. The feature set of Digger cloud (GitHub App) and Digger community edition is exactly the same, the difference is only where it is hosted. Please note that Digger Cloud is GitHub Only, for Bitbucket & Gitlab you'd have to Self Manage it, unless you want a dedicated instance under an enterprise license. +All of Digger is open source, even the enterprise edition. The feature set of Digger cloud (GitHub App) and Digger community edition is exactly the same, the difference is only where it is hosted. Please note that Digger Cloud is GitHub Only, for Bitbucket & GitLab you'd have to Self Manage it, unless you want a dedicated instance under an enterprise license. -To self-host the enterprise edition, you'd need to buy a license (same as with Gitlab and other commercial open-source products). +To self-host the enterprise edition, you'd need to buy a license (same as with GitLab and other commercial open-source products). **For anyone using Digger, are all of the enterprise features in the open source codebase?** @@ -53,7 +53,7 @@ Yes We ask users to bring their own compute and state management system as we believe that the number of privileged environments in an organisation needs to be kept to a minimum. The orchestrator backend, therefore, does not have access to your cloud account, states, plans, tfvars, or any other sensitive data. -For Digger Enterprise, users pay for Audit Log Retention, SAML, SSO & SCIM, Private VCS support (Github, Gitlab and Bitbucket), Compliance Frameworks and Enterprise Support. Book a [demo](https://calendly.com/diggerdev/diggerdemo) here if you’re interested. +For Digger Enterprise, users pay for Audit Log Retention, SAML, SSO & SCIM, Private VCS support (GitHub, GitLab and Bitbucket), Compliance Frameworks and Enterprise Support. Book a [demo](https://calendly.com/diggerdev/diggerdemo) here if you’re interested. We truly value community feedback and suggestions. Feel free to join our [slack](https://bit.ly/diggercommunity) if you have any questions that aren’t answered above. diff --git a/docs/team/getting-started/gha-aws.mdx b/docs/team/getting-started/gha-aws.mdx index 738415fe1..3131112a8 100644 --- a/docs/team/getting-started/gha-aws.mdx +++ b/docs/team/getting-started/gha-aws.mdx @@ -33,7 +33,7 @@ Create a `digger_workflow.yml` file under `.github/workflows` in your repo with In order to be triggered, the workflow file with the exact same name must - exist in the default branch. Github will use the file from a relevant branch - + exist in the default branch. GitHub will use the file from a relevant branch - but it will throw a 404 error if a workflow with the same name is not found in the default branch.