phoenix_container_example
embedded-postgres
phoenix_container_example | embedded-postgres | |
---|---|---|
9 | 5 | |
19 | 323 | |
- | 1.9% | |
9.1 | 6.4 | |
5 days ago | 28 days ago | |
HCL | Java | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
phoenix_container_example
-
Testcontainers
It's particularly useful for testing a set of microservices.
See https://github.com/cogini/phoenix_container_example for a full example.
-
Musl 1.2.4 adds TCP DNS fallback
I use distroless images based on Debian or Ubuntu, e.g., https://github.com/cogini/phoenix_container_example
The result is images the same size as Alpine, or smaller, without the incompatibilities. I think Alpine is a dead end.
-
Where do you build your image in your pipeline?
Here is a full-featured example of building images in GitHub Actions that includes optimized caching: https://github.com/cogini/phoenix_container_example/blob/master/.github/workflows/ci-ghcr.yml
-
AWS Devops tools vs Bitbucket
Here are some examples of using GitHub actions to build, or call hosted runners in AWS to build Arm images, and using OIDC to manage AWS credentials: https://github.com/cogini/phoenix_container_example/blob/master/.github/workflows/
-
Running python when building a Docker image on AWS
Parameter Store is a good place to store things. ECS can read from it and set variables. This is a complete example of using Terraform to manage infrastructure with EC2 or ECS: https://github.com/cogini/multi-env-deploy Here is an app that runs in ECS: https://github.com/cogini/phoenix_container_example This task file sets env vars based on parameter store: https://github.com/cogini/phoenix_container_example/blob/master/ecs/taskdef.json
- Advice on CI/CD at scale from GitHub Enterprise to CodePipeline (TF & CFN) ?
-
When would you introduce Docker to your project?
Here is a complete example project which shows how to use Earthly and Visual Studio Code .devcontainer: https://github.com/cogini/phoenix_container_example
- I wrote A blog post about my experience trying to use buildkit caching to speed up CI
-
We are the AWS Containers Team - Ask the Experts - Feb 10th @ 11AM PT / 2PM ET / 7PM GMT!
I am heavily using multi-stage builds, e.g.: https://github.com/cogini/phoenix_container_example/blob/master/deploy/Dockerfile.alpine
embedded-postgres
- Testcontainers
-
Why you should probably be using SQLite
Little use if you’re not on the JVM but I’ve had great success with Embedded Postgres:
https://github.com/zonkyio/embedded-postgres
Each test just copies a template database so it’s ultra fast and avoids the need for complicated reset logic.
-
Ask HN: What's your favorite software testing framework and why?
Outside of differences between assertion-based unit tests and property-based tests (both of which are worth doing), I don't think framework makes much difference. But your approach to testing definitely does.
I think every language having its own testing framework is good, even for things like functional tests which can often be externalised. Tests are an essential part of every project and should be well integrated with the rest of the codebase and the team creating it. Often, the tests are the only good place to go and see what an app actually _does_ and so they form an essential part of the documentation.
In my experience it's very rare that you can effectively create and maintain something like Cucumber tests owned by anyone but the team implementing the code so there's little benefit to translating from a text DSL like that. But the language used is definitely useful, so what I like to see is code in the implementation language that matches the Given/When/Then structure of those tests, but instead of reusable text steps you just have reusable functions which take parameters. This means you can easily refactor, and use the full functionality of your IDE to suggest and go to definitions etc. No matter what, you should treat your test code the same way you do everything else - abstractions matter, so functional tests at the top level should rarely just be about clicking on things and asserting other things, they should be in the language of the domain.
Functional tests are worth much more than unit tests. No only do they test the only things of actual business value, they are also more robust in the face of implementation refactorings and so require less rework (unless you're being overly specific with CSS selectors etc). Unit tests are often highly coupled to specific implementations and can be a poor investment, especially early in a project. I believe a good balance is functional and integration tests that explore the various paths through your app and prove everything's hooked up, coupled with property based unit tests for gnarly or repetitive logic that isn't worth endlessly iterating via the UI. All other unit tests are optional and at the discretion of the implementer.
You should be able to mock out every major articulation point in your code, but it's generally preferable if you can mock _real_ dependencies. That is, instead of mocking out a 'repository' abstraction that looks stuff up and returns canned data, have a real test database against which you look up real data (created by steps in your functional tests). This reduces risk and cognitive overhead (you're not having to encode too many assumptions in your test suite) and doesn't have to be as slow as people like to make out - Embedded Postgres is quite fast, for example:
https://github.com/zonkyio/embedded-postgres
Same with network services - it's not slow to chat to localhost and you'll find more issues testing proper round-trips. I have not found "assert that you called X" style testing with mocks useful - you care about outcomes, not implementation details.
Beyond all that, as long as you can make assertions that generate clear error messages, you're fine.
-
Hctree is an experimental high-concurrency database back end for SQLite
I use an embedded postgres testing library for the JVM that does something along those lines.
Well no actually it just unpacks the tar file in a temp dir and runs the full postgres, but it mostly feels like what you describe (minus the single file part) and starts surprisingly fast. That would totally work for a little proof of concept (https://github.com/zonkyio/embedded-postgres)
- Thoughts on Micronaut vs. Quarkus?
What are some alternatives?
elixir-boilerplate - ⚗ The stable base upon which we build our Elixir projects at Mirego.
greenlight - Clojure integration testing framework
amazon-ecs-agent - Amazon Elastic Container Service Agent
postgresql-embedded - Embedded PostgreSQL Server
ecs-deploy - Simple shell script for initiating blue-green deployments on Amazon EC2 Container Service (ECS)
testy - test helpers for more meaningful, readable, and fluent tests
multi-env-deploy - Complete example of deploying complex web apps to AWS using Terraform, Ansible, and Packer
php-easycheck - Mirror of http://chriswarbo.net/git/php-easycheck
Veil - Simple passwordless authentication for your Phoenix apps
ospec - Noiseless testing framework
NuGet - NuGet Gallery is a package repository that powers https://www.nuget.org. Use this repo for reporting NuGet.org issues.
datadriven - Data-Driven Testing for Go