28fe571543
* Remove _build folders for umbrella apps
For umbrella apps everything goes into /_build directory so there no need to ignore directories that should never be created
* Change mix aliases to be more aligned with what OS community would expect
1. We want ecto.create and ecto.migrate to be run on each tests, this will simplify setup steps (no need to run migrations manually)
2. ecto.remigrate is not needed because now you can just run ecto.drop and on tests migrations would be executed anyways.
* Rename docker-compose step name in CONTRIBUTING.md
The step was renamed here: dd67baf629 (diff-67a4805fdcc6145d7b3ada2a6099a9b2e91c9d0fd108c22f95d2f01d219793d1R10)
* Remove .devcontainer
This an is opinionated change. Right now devcontainer doesn't work but should be easy to fix (with renaming step name), but at the same time it forces developers that use VS code to have unified development environment (including plugins for the editor itself).
I feel like it's not a good path to go for OS and for small team - everyone should be allowed to use setup they like. Especially for people like me that tend to recompile ls-elixir for Elixir plugin from master branch.
Plus it's yet another thing to maintain while nobody on the team is using it, which means it will be always causing issues.
* Make fz_http mix.exs aliases aligned with umbrella app ones
* Redirect stderr to stdout in a command called from dev.exs
Otherwise I'm getting this on my MacOS (that has a `route` implementation that doesn't show interfaces) when `mix phx.server` is executed:
```
usage: route [-dnqtv] command [[modifiers] args]
```
* Fix race condition due to static device field values
Both public_key and name are unique and we should not use static values for field covered by unique index, otherwise deadlocks and slow tests are expected.
* Remove unwanted transaction block
The changeset code doesn't have any code that accesses the database and individual Ecto.SQL commands are already wrapped in transactions by default, so there is no need to start it manually and hold for longer than expected (while irrelevant Elixir code is running).
* Use netstat to identify egress interface on MacOS
* Rename uninstall.sh to omnibus-uninstall.sh
* Fix uninstall path in omnibus_build.yml
firezone Omnibus project
This project creates full-stack platform-specific packages for
firezone!
Installation
You must have a sane Ruby 2.0.0+ environment with Bundler installed. Ensure all the required gems are installed:
$ bundle install --binstubs
Usage
Build
You create a platform-specific package using the build project command:
$ bin/omnibus build firezone
The platform/architecture type of the package created will match the platform
where the build project command is invoked. For example, running this command
on a MacBook Pro will generate a Mac OS X package. After the build completes
packages will be available in the pkg/ folder.
Clean
You can clean up all temporary files generated during the build process with
the clean command:
$ bin/omnibus clean firezone
Adding the --purge purge option removes ALL files generated during the
build including the project install directory (/opt/firezone) and
the package cache directory (/var/cache/omnibus/pkg):
$ bin/omnibus clean firezone --purge
Publish
Omnibus has a built-in mechanism for releasing to a variety of "backends", such
as Amazon S3. You must set the proper credentials in your
omnibus.rb config file or specify them via the command line.
$ bin/omnibus publish path/to/*.deb --backend s3
Help
Full help for the Omnibus command line interface can be accessed with the
help command:
$ bin/omnibus help
Version Manifest
Git-based software definitions may specify branches as their
default_version. In this case, the exact git revision to use will be
determined at build-time unless a project override (see below) or
external version manifest is used. To generate a version manifest use
the omnibus manifest command:
omnibus manifest PROJECT -l warn
This will output a JSON-formatted manifest containing the resolved version of every software definition.
Kitchen-based Build Environment
Every Omnibus project ships with a project-specific
Berksfile that will allow you to build
your omnibus projects on all of the platforms listed in the
.kitchen.yml. You can add/remove additional platforms as
needed by changing the list found in the .kitchen.yml
platforms YAML stanza.
This build environment is designed to get you up-and-running quickly. However, there is nothing that restricts you from building on other platforms. Simply use the omnibus cookbook to setup your desired platform and execute the build steps listed above.
The default build environment requires Test Kitchen and VirtualBox for local development. Test Kitchen also exposes the ability to provision instances using various cloud providers like AWS, DigitalOcean, or OpenStack. For more information, please see the Test Kitchen documentation.
Once you have tweaked your .kitchen.yml (or
.kitchen.local.yml) to your liking, you can bring up an
individual build environment using the kitchen command.
$ bin/kitchen converge ubuntu-1804
Then login to the instance and build the project as described in the Usage section:
$ bin/kitchen login ubuntu-1804
[vagrant@ubuntu...] $ . load-omnibus-toolchain.sh
[vagrant@ubuntu...] $ [ -e .bundle ] && sudo chown -R vagrant:vagrant .bundle
[vagrant@ubuntu...] $ cd firezone # or 'cd firezone/omnibus' if your omnibus project is embedded in your main project
[vagrant@ubuntu...] $ bundle install
[vagrant@ubuntu...] $ bin/omnibus build firezone
For a complete list of all commands and platforms, run kitchen list or
kitchen help.