You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+8-2Lines changed: 8 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,7 +20,7 @@ and we would be happy to set you up.
20
20
21
21
## Introduction
22
22
23
-
Digger is an open source terraform cloud alternative. We believe that open source software is important, and we welcome contributions from anyone who is interested in making our tool better.
23
+
Digger is an open source terraform cloud alternative. We believe that open source software is important, and we welcome contributions from anyone who is interested in making our platform better.
24
24
This document is intended to be a guide for people who want to contribute to Digger. We appreciate all contributions, no matter how big or small.
25
25
26
26
## How to contribute
@@ -51,6 +51,7 @@ libs/ # contains libraries that are common between digger cli and digger cloud b
51
51
cli/cmd/ # contains the main cli files
52
52
cli/pkg/ # contains packages that are used by the cli code, can import from libs/
53
53
backend/ # contains the backend code, can import from libs/
54
+
ee/ # contains the ee code, can import from libs/ and the other ce packages (but ce must not import from ee)
54
55
docs/ # contains documentation pages
55
56
```
56
57
@@ -64,7 +65,7 @@ When you have made changes to the codebase that you would like to contribute bac
64
65
4. Test out your changes in a demo GitHub repository using Github Actions.
65
66
66
67
- You can test out the changes from your fork by referencing the Action within a Github workflow file: `uses: <github-username>/digger@your-branch`.
67
-
- Fork [this demo repository](https://github.com/diggerhq/digger_demo_multienv) to setup and assert your tests.
68
+
- Fork [this demo repository](https://github.com/diggerhq/demo-opentofu) to setup and assert your tests.
68
69
- If you're adding new app level inputs that implies new environment variables, make sure to reference them **both within the `build digger` and `run digger` steps** in [`action.yml`](./action.yml).
69
70
70
71
5. Update the documentation to reflect your changes, if applicable.
@@ -81,6 +82,11 @@ When you have made changes to the codebase that you would like to contribute bac
81
82
- Once we are ready we tag the head of our release branch and perform a release on it.
82
83
- Tagged releases are published as actions and they are the most suitable to be used in production.
83
84
85
+
86
+
## How to test locally
87
+
88
+
The easiest way to test locally is to follow our [Testing locally](https://docs.digger.dev/ce/contributing/setup-dev-environment) instructions.
89
+
84
90
## Code of Conduct
85
91
86
92
We expect all contributors to follow our [Code of Conduct](https://www.contributor-covenant.org/version/2/1/code_of_conduct/) when participating in our community. Please read it carefully before contributing.
ALLOW_DIRTY=false # set to true if the database has already a schema configured
58
+
```
59
+
60
+
note that you would need to source this file before running the backend service
61
+
62
+
```
63
+
set -a
64
+
source .env
65
+
set +a
66
+
```
67
+
68
+
And after that you can run the service with:
69
+
70
+
```
71
+
go run backend/main.go
72
+
```
73
+
74
+
You should see a message that the service is listening on port 3000. Visiting that url should show you a ui screen that digger is up and running.
75
+
</Step>
76
+
77
+
<Steptitle="Next steps">
78
+
From here on you can follow the steps in the self hosting binary guide [here](/ce/self-host/deploy-binary)
79
+
</Step>
80
+
81
+
</Steps>
82
+
83
+
## Setting up the cli
84
+
85
+
The cli is mainly meant to be used and invoked in CI systems. So in order to test cli changes the easiest way is to push it to your digger branch and then update the step to point to the branch directly:
86
+
87
+
```
88
+
- name: digger
89
+
uses: diggerhq/digger@feat/my-test-branch
90
+
with:
91
+
....
92
+
```
93
+
94
+
Digger will then build the cli on your test runs and so you can test your changes from branch. It can be time consuming to build the cli on every run so we also added a way to use it from local
95
+
via self-hosted runners on your machine. In order to achieve this you would need to create a self-hosted runner connected to your repo.
96
+
97
+
Visit the repo with your test terraform and then click on "actions" -> "runners" -> "self-hosted runners" -> "new runner".
98
+
Follow the instructions for your local machine and to set it up. Once set up you should see it in the list of runners.
99
+
100
+
From here you will need to build a version of your cli locally.
101
+
102
+
```
103
+
cd cli
104
+
go build -o digger ./cmd/digger
105
+
chmod +x digger
106
+
```
107
+
108
+
Test run the local cli - it should display a message like "no CI detected". Now we can modify our workflow file to use our self-hosted runner and to invoke the local cli during processing:
109
+
110
+
```
111
+
- name: digger
112
+
uses: diggerhq/digger@vLatest # this version doesn't matter when using local dev
The value of "local-dev-cli-path" should be an absolute path to the location compiled binary from the previous step (excluding the binary name). You should see this line when you try to run it:
> **Security Warning**: Self-hosted runners have significant security implications. When using self-hosted runners, be aware that:
124
+
> - Code from pull requests can run on your self-hosted runner, potentially executing malicious code on your machine
125
+
> - If your repository is public, anyone can fork it and submit a pull request that could run code on your runner
126
+
> - Only use self-hosted runners in private repositories where you trust all contributors, or implement proper security controls
127
+
> - For more information, see [GitHub's security considerations for self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#self-hosted-runner-security)
128
+
129
+
From here onwards the cycle is to make a local change, rebuild the cli and then trigger in github to test that change. Its a much faster iterative cycle in comparison to building from a branch each time.
0 commit comments