Add details for sourcing files from project repository for version-co…

…ntrolled projects (#2155)

dictionary-octopus.txt

@@ -154,6 +154,8 @@ tagset
 templateid
 templating
 tenanttype
+tfvar
+tfvars
 TFVC
 tmpfs
 Traefik

src/pages/docs/deployments/custom-scripts/run-a-script-step.md

@@ -56,6 +56,12 @@ You may also select the source of the script, either:
 Using scripts from inside a package or a git repository are a great way to version and source control your scripts. (You can be assured the correct version of your script will be run when deploying each version of your application.) Both methods have benefits and suit different applications: choose the method best suited to your situation.
 :::
 
+:::div{.hint}
+From Octopus **2024.1**, if you are storing your project configuration in a Git repository using the [Configuration as code feature](/docs/projects/version-control), you can source files from the same Git repository as your deployment process by selecting Project as the Git repository source. When creating a Release, the commit hash used for your deployment process will also be used to source the files.
+
+You can find more information about this feature in this [blog post on using Git resources directly in deployments](https://octopus.com/blog/git-resources-in-deployments).
+:::
+
 :::div{.hint}
 When sourcing a script from a file inside a package you cannot choose to run the step before packages are acquired.
 :::

src/pages/docs/deployments/kubernetes/deploy-raw-yaml/index.md

@@ -27,6 +27,12 @@ Sourcing from Git Repositories was added in Octopus **2023.3**.
 You can find more information about this feature in [this blog post](https://octopus.com/blog/manifests-from-git).
 :::
 
+:::div{.info}
+From Octopus **2024.1**, if you are storing your project configuration in a Git repository using the [Configuration as code feature](/docs/projects/version-control), you can source your YAML from the same Git repository as your deployment process by selecting Project as the Git repository source. When creating a Release, the commit hash used for your deployment process will also be used to source the YAML files.
+
+You can find more information about this feature in this [blog post on using Git resources directly in deployments](https://octopus.com/blog/git-resources-in-deployments).
+:::
+
 :::div{.warning}
 Sourcing from a Git repository clones the whole repository onto Octopus Server during a deployment. Ensure that you **do not have any sensitive data** in your git repository.
 :::

src/pages/docs/deployments/kubernetes/helm-update/index.md

@@ -9,7 +9,13 @@ navOrder: 40
 
 Helm Charts are like a package manager for Kubernetes applications, allowing users to reuse and share complex resource configurations.
 
-## Helm feed
+## Helm chart sources
+
+You can source your Helm charts from two different sources:
+- Packages from Helm or OCI feeds
+- Git Repository - *New!*
+
+### Helm feed
 A Helm Feed in Octopus refers to a [Helm Chart repository](https://helm.sh/docs/topics/chart_repository/). This repository is effectively just an HTTP server that houses an `index.yaml` which describes the charts available on that server. Octopus uses this index file to determine the available "packages" (Charts) and versions. A chart is a tarball that looks like `alpine-0.1.2.tgz` which for this example Octopus will interpret as having PackageID `alpine` and version `0.1.2`. There are various ways you can host a chart repository, including third-party tools like [ChartMuseum](https://github.com/chartmuseum/chartmuseum), [Artifactory](https://www.jfrog.com/confluence/display/JFROG/Kubernetes+Helm+Chart+Repositories), [Cloudsmith](https://help.cloudsmith.io/docs/helm-chart-repository), or even hosting your own [static web server](https://helm.sh/docs/topics/chart_repository/#hosting-chart-repositories).
 
 :::figure
@@ -37,7 +43,7 @@ If the `.tgz` does not have a `chart.yaml` file, the PackageID and version are i
 
 For more information about Helm Chart repositories and how to run your own private repository, check out the living documentation on their [GitHub repo](https://helm.sh/docs/topics/chart_repository/).
 
-## OCI-based registry feed
+### OCI-based registry feed
 
 :::div{.info}
 Octopus version `2023.3.4127` added support for Helm repositories stored in OCI-based registries.
@@ -53,6 +59,30 @@ An OCI-based registry can contain zero or more Helm repositories and each of tho
 
 For more information about using OCI-based registries and how to run your own private repository, check out the living documentation on their [GitHub repo](https://helm.sh/docs/topics/registries/).
 
+### Git repository
+
+:::div{.info}
+Octopus version `2024.1` added support for Helm charts stored in Git repositories.
+
+You can find more information about this feature in this [blog post on using Git resources directly in deployments](https://octopus.com/blog/git-resources-in-deployments).
+:::
+
+Sourcing your Helm charts from a Git Repository can streamline your deployment process by reducing the amount of steps required to get them into Octopus.
+
+To configure a Git Repository source, select the `Git Repository` option as your Chart Source. 
+
+#### Database projects
+
+If you are storing your project configuration directly in Octopus (i.e. not in a Git repository using the [Configuration as code feature](/docs/projects/version-control)), you can source your charts from a Git repository by entering the details of the repository, including:
+- URL
+- Credentials (either anonymous or selecting a Git credential from the Library)
+
+When creating a Release, you choose the tip of a branch for your Helm charts. The commit hash for this branch is saved to the Release. This means redeploying that release will only ever use that specific commit and not the _new_ tip of the branch.
+
+#### Version-controlled projects
+
+If you are storing your project configuration in a Git repository using the [Configuration as code feature](/docs/projects/version-control), in addition to the option above, you can source your charts from the same Git repository as your deployment process by selecting **Project** as the Git repository source. When creating a Release using this option, the commit hash used for your deployment process will also be used to source the chart files.
+
 ## Helm upgrade step
 Since the [helm upgrade](https://docs.helm.sh/helm/#helm-upgrade) command provides the ability to ensure that the chart is installed when it runs for the first time (by using the `--install` argument), this upgrade command is the most practical step to provide.
 

src/pages/docs/deployments/kubernetes/kustomize/index.md

@@ -11,6 +11,12 @@ Octopus supports the deployment of Kubernetes resources through the **Kustomize*
 
 This step allows you to source your **Kustomize** files from git, perform variable substitutions based on your environment and/or tenant and finally apply the changes to your Kubernetes clusters.
 
+:::div{.info}
+From Octopus **2024.1**, if you are storing your project configuration in a Git repository using the [Configuration as code feature](/docs/projects/version-control), you can source your Kustomize files from the same Git repository as your deployment process by selecting Project as the Git repository source. When creating a Release, the commit hash used for your deployment process will also be used to source the Kustomize files.
+
+You can find more information about this feature in this [blog post on using Git resources directly in deployments](https://octopus.com/blog/git-resources-in-deployments).
+:::
+
 :::figure
 ![Kustomize step](/docs/deployments/kubernetes/kustomize/kustomise-step.png)
 :::

src/pages/docs/deployments/terraform/working-with-built-in-steps/index.md

@@ -33,7 +33,10 @@ Using credentials managed by Octopus is optional, and credentials defined in the
 
 ## Template section 
 
-The Terraform template can come from two sources: directly entered source code or from files in a package.
+The Terraform template can come from three sources:
+- Directly entered source code
+- Files in a package
+- Files in a Git repository - *New!*
 
 ### Source code
 
@@ -77,6 +80,31 @@ Given that Terraform templates and variable files are plain text, you may find i
 ![Package](/docs/deployments/terraform/working-with-built-in-steps/images/step-aws-package.png)
 :::
 
+### Git repository
+
+:::div{.info}
+Octopus version `2024.1` added support for Terraform files stored in Git repositories.
+
+You can find more information about this feature in this [blog post on using Git resources directly in deployments](https://octopus.com/blog/git-resources-in-deployments).
+:::
+
+The third option is to use files container in a Git repository. This can streamline your deployment process by reducing the amount of steps required to get them into Octopus as you no longer need to package the files up and put them into a feed.
+
+To configure Terraform steps to use a Git repository, select the `Git Repository` option as your Template Source.
+
+#### Database projects
+
+If you are storing your project configuration directly in Octopus (i.e. not in a Git repository using the [Configuration as code feature](/docs/projects/version-control)), you can source your files from a Git repository by entering the details of the repository directly on the step, including:
+
+- URL
+- Credentials (either anonymous or selecting a Git credential from the Library)
+
+When creating a Release, you choose the tip of a branch for your files. The commit hash for this branch is saved to the Release. This means redeploying that release will only ever use that specific commit and not the _new_ tip of the branch.
+
+#### Version-controlled projects
+
+If you are storing your project configuration in a Git repository using the [Configuration as code feature](/docs/projects/version-control), in addition to the option above, you can source your files from the same Git repository as your deployment process by selecting **Project** as the Git repository source. When creating a Release using this option, the commit hash used for your deployment process will also be used to source the files.
+
 ### Variable replacements
 
 Variable replacement is performed before the template is applied or destroyed when defined in either an inline script or a package.