This reduces merge conflicts when 2 PRs both want to make the first
change to a draft entry
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
1. `asdf install` doesn't seem to list which plugins you need, so we
explain that
2. No longer recommending `brew` for installing `pre-commit` since all
systems should have `pip` from `asdf` by the time they reach this step
3. Explain how to install from `requirements.txt` since that is needed
for all the pre-commit stuff to run like prettier and codespell.
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
- Adds `http_test_server_image` to inputs so that it gets set properly
for CI (`debug`) and CD (`perf`)
- Updates `dev` -> `debug` in docker-compose.yml to fix pulls
- Fixes issue with seeds and relevant docs from #6205
These are now published at
https://www.github.com/firezone/terraform-aws-gateway and
https://www.github.com/firezone/terraform-azurerm-gateway to match the
unclear docs for registry module naming...
- Adds the AWS equivalent of our GCP scalable NAT Gateway.
- Adds a new kb section `/kb/automate` that will contain various
automation / IaaC recipes going forward. It's better to have these
guides in the main docs with all the other info.
~~Will update the GCP example in another PR.~~
Portal helper docs in the gateway deploy page will come in another PR
after this is merged.
Unfortunately I had to keep `linux-client` to get the compatibility
tests to pass. #4578 aims to remove that package.
Please add to this list if you think of anything:
```[tasklist]
# Things that may break that CI/CD won't catch
- [ ] Github release artifacts
- [ ] Knowledge base
- [ ] Docker images
- [ ] Docker containers
- [ ] Existing `linux-client` users
- [ ] Anything that downloads ghcr artifacts
- [ ] Nix (Not sure if it's built in CI. It had a merge conflict)
```
Refs #4515, and #3712, #3782
I think this is what Thomas and I agreed on in Slack / Github
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
This example will work once our latest gateway is pushed to GitHub
Container Registry, but to test it for now a few overrides can be added
to the `main.tf` to use our Google Artifact Registry and local module
instead:
```diff
module "gateways" {
-- source = "github.com/firezone/firezone/terraform/modules/google-cloud/apps/gateway-region-instance-group"
++ source = "../../../modules/google-cloud/apps/gateway-region-instance-group"
...
++ container_registry = "us-east1-docker.pkg.dev"
++ image_repo = "firezone-prod/firezone"
++ image = "gateway"
}
```
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Signed-off-by: Andrew Dryga <andrew@dryga.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Adds a working example of the simplest way to deploy Gateways to GCP
that is also mostly cloud platform agnostic.
I avoided using COS and Docker for this because:
- Systemd is already installed and supports IPv6 already
- Can be more easily adapted to other platforms where Docker may not be
available or trickier to setup (E.g. CentOS 7)
- COS is Google-specific
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Andrew Dryga <andrew@dryga.com>
Some recent changes to the Rust part of the codebase made it quite
difficult to locally build the project due to tauri's heavy dependencies
on WebKitGTK and other native libraries.
I tried working around this on my local (nix) machine and found it quite
difficult. The cleanest way here is to make use of what Nix calls
"devshells" which give you an environment specifically for hacking on
your project.
Unfortunately, these files need to be tracked in version control and
cannot be ignored (at least I've not found a way to do that). Given that
we already have a lot of clutter in our repository, I put them under
`scripts/nix`.
They are generally useful. I also added a `.envrc` file which
automatically launches the dev-shell. As a result, you have a shell
ready to go with all your dependencies as soon as you `cd` into our
repository (assuming you use `direnv` and it is hooked up with your
shell).
I didn't really want to have any of my local setup leak into the repo
because I think apart from me and @conectado, nobody is using nix, thus
I hope this minimal footprint is an okay compromise.
* Add new `VERSION` to `docker_migrate.sh` script
* Add missing `SAML_KEYFILE_PATH` and `SAML_CERTFILE_PATH` env vars to
migrate script
* Add missing `PHOENIX_PORT` var
* Bump Elixir to 1.14.3
* Bump Erlang to 25.2.1
* Update docs to document new VERSION var in docker-compose.yml upgrade
mechanism
Fixes#1395
There's been some confusion lately over the change to disable
auto-create users by default, so this PR aims to document the choice a
little more clearly.
Refs #1362#1117
Co-authored-by: Andrew Dryga <andrew@dryga.com>
Adds a minimal supervision tree for making DB changes from the
`FzHttp.Release` module. This allows the `bin/create-or-reset-admin` and
`bin/create-api-token` commands to be with `docker compose exec` or
`docker compose run --rm` indiscriminately.
Starting the FzHttp.Repo directly is more involved it's not compiled
into the release as an OTP app.
1. The test data is taken from tests, you can override attributes by
adding keyword params to `doc` macro;
2. Additionally, you can add a section title using a `@moduledoc` in a
controller and a controller action title using `@doc` on a controller
function. (It will be added to all instances of its usage).
3. To make parameters nice a helper was added to build it using
`DocHelper`, you can find an example in UserController.
Overall, the code is messy, I'll need to revisit it, but was doing it in
a rush so hope it's good enough for v0.
Results you can see at https://firezone.docs.apiary.io/.
To generate it locally run `DOC=1 mix test
test/fz_http_web/controllers/json`.
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
