PhoenixBootstrap

This is an opinionated Phoenix project that can be used as a starter template for your project. It uses the default options of the mix phx.new command, with added libraries and CI.

The following are the defaults at the time the project was generated/updated:

• postgres for the DB adapter
• bandit for HTTP adapter
• assets configured (tailwind and esbuild)
• Swoosh mailer files
• LiveView configured
• not an umbrella project

How to use

Clone the repo:

git clone [email protected]:anderkonzen/phoenix_bootstrap.git

Change directory and run the commands:

cd phoenix_bootstrap
mix setup
iex -S mix phx.server

Now you can visit localhost:4000 from your browser.

Dependencies

The project contains the following dependencies set up:

• credo
• dialyxir
• sobelow
• mix_audit

The above dependencies/libraries aim to add standardization, as well as enable security validations and static code analysis.

Note: if you want to make checks on the project's documentation, I recommend checking the Doctor package.

CI

The CI pipeline uses all the aforementioned tools to check for security issues (both in code and dependencies), perform code static analysis, test and build.

The steps used in the CI are as follow:

• compilation (basically mix deps.get, mix compile --warnings-as-errors --all-warnings)
• linting and security, with mix credo --strict, mix format --check-formatted and mix sobelow --config
• dependencies audit, with mix hex.audit, mix deps.audit, mix deps.unlock --check-unused
• dialyzer
• tests with mix test --warnings-as-errors --raise (they are partitioned)

The following mix aliases are available in the project: mix ci, mix lint and mix deps_audit.

Note

You will find a somewhat complex CI pipeline with reusable workflows and composite actions. This is on purpose and it aims to show you how can you achieve such customized flow, ie., version matrix, partitioned tests with unified coverage data, etc.

Release and Docker

The last step of the CI builds and publishes a Docker image to the Docker Hub registry. The project is configured as a release, so the Dockerfile is optimized for such configuration.

It also uses the official Docker GitHub Actions and caching in order to make the image build step faster.

Note

Two secrets (DOCKERHUB_TOKEN and DOCKERHUB_USERNAME) were added to the GitHub repo for the actions to work. You may need to change this configuration for it to work in your environment.

Check the Actions page to see it in action.

Other things you can try

Other than the tools already mentioned, the following tools are suggestions I believe can improve the overall devex:

• https://github.com/randycoulman/mix_test_interactive

TODOs

• Add a way to easily rename the project (some alternatives here and here)