run formatters

Signed-off-by: Kristoffer Dalby <[email protected]>

CHANGELOG.md

@@ -45,7 +45,7 @@ after improving the test harness as part of adopting [#1460](https://github.com/
  - `use_username_in_magic_dns` can be used to turn this behaviour on again, but note that this option _will be removed_ when tags are fixed.
  - dns.base_domain can no longer be the same as (or part of) server_url.
  - This option brings Headscales behaviour in line with Tailscale.
-- YAML files are no longer supported for headscale policy.  [#1792](https://github.com/juanfont/headscale/pull/1792)
+- YAML files are no longer supported for headscale policy. [#1792](https://github.com/juanfont/headscale/pull/1792)
  - HuJSON is now the only supported format for policy.
 - DNS configuration has been restructured [#2034](https://github.com/juanfont/headscale/pull/2034)
  - Please review the new [config-example.yaml](./config-example.yaml) for the new structure.

CONTRIBUTING.md

@@ -9,7 +9,7 @@ Headscale has a small maintainer team that tries to balance working on the proje
 
 When we work on issues ourselves, we develop first hand knowledge of the code and it makes it possible for us to maintain and own the code as the project develops.
 
-Code contributions are seen as a positive thing. People enjoy and engage with our project, but it also comes with some challenges; we have to understand the code, we have to understand the feature, we might have to become familiar with external libraries or services and we think about security implications. All those steps are required during the reviewing process. After the code has been merged, the feature has to be maintained. Any changes reliant on external services must be updated and expanded accordingly. 
+Code contributions are seen as a positive thing. People enjoy and engage with our project, but it also comes with some challenges; we have to understand the code, we have to understand the feature, we might have to become familiar with external libraries or services and we think about security implications. All those steps are required during the reviewing process. After the code has been merged, the feature has to be maintained. Any changes reliant on external services must be updated and expanded accordingly.
 
 The review and day-1 maintenance adds a significant burden on the maintainers. Often we hope that the contributor will help out, but we found that most of the time, they disappear after their new feature was added.
 

docs/remote-cli.md

@@ -47,40 +47,40 @@ headscale apikeys expire --prefix "<PREFIX>"
 
 3. Make `headscale` executable:
 
-  ```shell
-  chmod +x /usr/local/bin/headscale
-  ```
+ ```shell
+ chmod +x /usr/local/bin/headscale
+ ```
 
 4. Configure the CLI through environment variables
 
-  ```shell
-  export HEADSCALE_CLI_ADDRESS="<HEADSCALE ADDRESS>:<PORT>"
-  export HEADSCALE_CLI_API_KEY="<API KEY FROM PREVIOUS STAGE>"
-  ```
+ ```shell
+ export HEADSCALE_CLI_ADDRESS="<HEADSCALE ADDRESS>:<PORT>"
+ export HEADSCALE_CLI_API_KEY="<API KEY FROM PREVIOUS STAGE>"
+ ```
 
-  for example:
+ for example:
 
-  ```shell
-  export HEADSCALE_CLI_ADDRESS="headscale.example.com:50443"
-  export HEADSCALE_CLI_API_KEY="abcde12345"
-  ```
+ ```shell
+ export HEADSCALE_CLI_ADDRESS="headscale.example.com:50443"
+ export HEADSCALE_CLI_API_KEY="abcde12345"
+ ```
 
-  This will tell the `headscale` binary to connect to a remote instance, instead of looking
-  for a local instance (which is what it does on the server).
+ This will tell the `headscale` binary to connect to a remote instance, instead of looking
+ for a local instance (which is what it does on the server).
 
-  The API key is needed to make sure that you are allowed to access the server. The key is _not_
-  needed when running directly on the server, as the connection is local.
+ The API key is needed to make sure that you are allowed to access the server. The key is _not_
+ needed when running directly on the server, as the connection is local.
 
 5. Test the connection
 
-  Let us run the headscale command to verify that we can connect by listing our nodes:
+ Let us run the headscale command to verify that we can connect by listing our nodes:
 
-  ```shell
-  headscale nodes list
-  ```
+ ```shell
+ headscale nodes list
+ ```
 
-  You should now be able to see a list of your nodes from your workstation, and you can
-  now control the `headscale` server from your workstation.
+ You should now be able to see a list of your nodes from your workstation, and you can
+ now control the `headscale` server from your workstation.
 
 ## Behind a proxy
 

proto/headscale/v1/headscale.proto

@@ -209,7 +209,6 @@ service HeadscaleService {
  }
  // --- Policy end ---
 
-
  // Implement Tailscale API
  // rpc GetDevice(GetDeviceRequest) returns(GetDeviceResponse) {
  // option(google.api.http) = {

proto/headscale/v1/policy.proto

@@ -5,17 +5,17 @@ option go_package = "github.com/juanfont/headscale/gen/go/v1";
 import "google/protobuf/timestamp.proto";
 
 message SetPolicyRequest {
- string policy = 1;
+  string policy = 1;
 }
 
 message SetPolicyResponse {
- string policy = 1;
- google.protobuf.Timestamp updated_at = 2;
+  string policy  = 1;
+  google.protobuf.Timestamp updated_at = 2;
 }
 
 message GetPolicyRequest {}
 
 message GetPolicyResponse {
- string policy = 1;
- google.protobuf.Timestamp updated_at = 2;
+  string policy  = 1;
+  google.protobuf.Timestamp updated_at = 2;
 }