{"id":39107446,"url":"https://github.com/ideacrew/ea_enterprise","last_synced_at":"2026-01-17T19:33:02.094Z","repository":{"id":38062279,"uuid":"385338840","full_name":"ideacrew/ea_enterprise","owner":"ideacrew","description":"Collection of containers to run Enroll in development context","archived":false,"fork":false,"pushed_at":"2025-08-25T20:12:58.000Z","size":187,"stargazers_count":0,"open_issues_count":16,"forks_count":0,"subscribers_count":19,"default_branch":"trunk","last_synced_at":"2025-08-25T22:11:52.223Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Dockerfile","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ideacrew.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2021-07-12T18:02:47.000Z","updated_at":"2025-08-07T17:27:36.000Z","dependencies_parsed_at":"2023-12-21T02:02:20.974Z","dependency_job_id":"a5de3bc4-0c5a-441a-b420-32851f985ed6","html_url":"https://github.com/ideacrew/ea_enterprise","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/ideacrew/ea_enterprise","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ideacrew%2Fea_enterprise","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ideacrew%2Fea_enterprise/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ideacrew%2Fea_enterprise/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ideacrew%2Fea_enterprise/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ideacrew","download_url":"https://codeload.github.com/ideacrew/ea_enterprise/tar.gz/refs/heads/trunk","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ideacrew%2Fea_enterprise/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28517123,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-17T18:55:29.170Z","status":"ssl_error","status_checked_at":"2026-01-17T18:55:03.375Z","response_time":85,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-01-17T19:33:01.437Z","updated_at":"2026-01-17T19:33:02.075Z","avatar_url":"https://github.com/ideacrew.png","language":"Dockerfile","funding_links":[],"categories":[],"sub_categories":[],"readme":"# ea_enterprise\nCollection of containers to run the Enroll ecosystem in a development context\n\n## Getting Started\n\nDownload and install Docker Desktop. **Important; this requires Docker Desktop 4.31 and Docker Compose 2.24 or higher.**\n\nClone the ea_enterprise repo:\n```\ngit clone https://github.com/ideacrew/ea_enterprise.git\n```\n\nCopy the env.dev.example to env.dev and change the values as needed (don't commit env files)\n```\ncp env.dev.example env.dev\n```\n\nEnsure the other repositories are present on your local machine and at the same level as ea_enterprise:\n\n- enroll\n- fdsh_gateway\n- medicaid_gateway\n- medicaid_eligibility\n- aca_entities\n- polypress\n- fti\n\nthe layout should look like this (you can change the *projects* folder)\n```\n~ /\n└── projects/\n    ├── ea_enterprise\n    ├── enroll\n    ├── fdsh_gateway\n    ├── medicaid_gateway\n    ├── aca_entities\n    ├── fti\n    └── polypress\n\n```\n\nBe sure all repositories are up to date with their respective release branches before running any commands!\nThe following command will update each of the sibling directories to the latest primary branch:\n```\nfor dir in . ../enroll ../fdsh_gateway ../medicaid_gateway ../aca_entities ../fti ../polypress; do\n    echo \"Pulling trunk in $(basename $dir)...\"\n    pushd $dir \u003e /dev/null \n    git checkout $(git branch --format='%(refname:short)' | egrep '^(main|trunk)$') \u0026\u0026 git pull \n    popd \u003e /dev/null\ndone\n```\n\n## Important concepts\n\n- inside the container: this means we will run a command inside the container (or \"guest\"), for example, `docker compose exec enroll /bin/bash` will run the command `/bin/bash` inside the container `enroll` from there we can execute any command that is available inside the container, for example, `rails c` will open a rails console inside the container\n\n- outside the container: this means we will run a command on the \"host\", usually in the context of the developer's Mac.\n\n## Profiles\nBy default, the docker-compose.yml is configured to only launch enroll and the required services to run it, however, other profiles can be used to launch other services, the profiles are:\n\n- all: launches all services\n- polypress: launches polypress\n- medicaid_gateway: launches medicaid_gateway / mitc\n- keycloak: launches keycloak\n- fdsh_gateway: launches fdsh_gateway\n- fti: launches fti\n- enroll_yard_doc: launches enroll documentation site\n\nthe profiles can be used like this:\n\n```\ndocker compose --profile polypress up\ndocker compose --profile all up\n```\n\nyou can also use multiple profiles at the same time\n\n```\ndocker compose --profile polypress --profile medicaid_gateway up\n```\n\n## Known workarounds\n\nSome of the workarounds are focused on making enroll running on Arm based Macs, technically speaking on intel Macs it can be installed directly on the host. You can use ea_enterprise on intel Macs, just comment the M1 hacks.\n\n### mongoid.yml\nThe services `fdsh_gateway`, `enroll` has \"localhost\" as the \"server\" on config/mongoid.yml, the Docker Compose configuration \"patches\" this by mounting anther configuration, the \"patched\" configuration is located at `config/mongoid.yml.docker` and is mounted on the container at `/{APP}/config/mongoid.yml`\n\n### Local aca_entities\naca_entities is already mounted and can be changed in the Gemfile - this allows local aca_entities modifications to be\nreflected when a rails server/console process is bounced, with no push to a remote or even bundle update/install required.\n\nThe trick to using the local gem is just to modify the already-built service you are working with (i.e., only Enroll if you are updating Enroll's Gemfile).\n  1. `docker compose build` if it has not run already (either on its own or as part of a previous run of `docker compose up`)\n  2. wait\n  3. modify the gemfile to point to the mounted file path: `gem 'aca_entities', path: \"/aca_entities\"`\n  4. start just enroll via the ui or command line *(do not restart everything)*\n\nNote that running a build with this local gem configuration in place will not currently work.\n\n### Remote gem updates/additions \nFor remote gem additions/updates, you can't successfully start the container/server after mod'ing the Gemfile. Building (`docker compose build`) after updating the Gemfile also produces an image that can't successfully start.\n\nThe solution is to start from an existing runnable container (Gemfile matches Gemfile.lock, and gems in lockfile are installed on the guest). Run the container and wait until fully started, then mod the Gemfile (leaving the container running).\nYou should then be able to `docker compose exec \u003cthe_service\u003e bundle install` in another terminal window. This will install the new/updated gem, and update the Gemfile.lock file on the guest and host - you can then commit the Gemfile.lock.\nFurther restarts of the container should be fine, and re-builds should also proceed happily.\n\n### Stimulus reflex on MG\nDocker Compose will patch MG stimulus reflex initializer to ignore dev:cache not being enabled, this is done via a volume mount on the docker-compose.yml file, the file is located at `hotpatches/stimulus_reflex.rb` and is mounted on the container at `/{APP}/config/initializers/stimulus_reflex.rb`. \n\n### Wicked pdf\nWicked pdf is patched to use the \"local\" binary (not the one from the wkhtmltopdf-binary-edge gem), this is done via a volume mount on the docker-compose.yml file, the file is located at `hotpatches/wicked_pdf.rb` and is mounted on the container at `/{APP}/config/initializers/wicked_pdf.rb`. The wicked pdf binary is installed on the container at `/usr/local/bin/wkhtmltopdf`\n\n## Basic Docker Compose Commands\nNote: commands must be run in the terminal from inside the ea_enterprise directory.\n\n- Start all services\n```\ndocker compose up\n```\n\n- Start **enroll** and any of its dependencies\n```\ndocker compose up enroll\n```\n\n- Start 2 services\n```\ndocker compose up enroll fdsh_gateway\n```\n- Rebuild all the containers  \n```\ndocker compose build\n```\n\n- Rebuild specific container (example; **enroll** container)\n```\ndocker compose build enroll\n```\n- Shell inside a container\n```\ndocker compose exec enroll /bin/bash\n```\n- Rubocop inside **enroll**\n```\ndocker compose exec enroll /enroll/rubocop_check_last_commit.sh\n```\n```\ndocker compose exec enroll /enroll/rubocop_check_pre_commit.sh\n```\n\n- docker compose \"exec vs run\"\n\nThe slight difference between exec and run is that run will create a new container, and exec will run the command on an existing container, examples;\n\n1. this will execute /bin/bash under the *running* container enroll. If there is no enroll running, the command will fail.\n\n```\ndocker compose exec enroll /bin/bash\n```\n2. this will create a new container and inside it will execute /bin/bash. If there is a container running, it will not be affected and create a new one in parallel. If there is no enroll running it will not fail.\n\n```\ndocker compose run enroll /bin/bash\n```\n\n## Restoring a database \n\nWith a `mongodb` compose service running, and a directory-based dump on your local(/host), run \n[mongo_restore_dump.sh](scripts%2Fmongo_restore_dump.sh) from your local. A bulk restore of multiple DB's or a targeted\nsingle DB (allowing for a DB rename) are supported (see script for details):\n\n```\n./scripts/mongo_restore_dump.sh [-r \u003crename_db_to\u003e] \u003cdump_dir_path\u003e\n```\n\n## Basic rails commands\n- start a rails console (inside the container):\n```\nrails c\n```\n \n- start a rails console (from outside, to the container)\n```\ndocker compose exec enroll rails c\n```\n\n- run tests (inside the container): \n```\nRAILS_ENV=test bundle exec rspec components/financial_assistance/spec/\n```\n\n- run test outside the container (cd to ea_enterprise first):\n```\ndocker compose exec -e \"RAILS_ENV=test\" enroll bundle exec rspec components/financial_assistance/spec/\n```\n\n## When do you need to restart the container?\n\nVery similar to the rules regarding when to restart a rails application \n\n- You changed something under /config \n- You need to switch branches\n- Additionally, if you alter a env variable set via docker configuration 'run-time' `*.env.dev` files\n\n## When to trigger an image rebuild \n\n- you added or deleted a gem\n- you changed anything in the docker-compose.yml file\n- you changed the Dockerfile of any container\n- you alter env variables set via the docker configuration 'build-time' `.env` file\n\n## Run the specs similar to how they run in Github Actions\n\nThe IdeaCrew GHA runs the specs as \"engines\" that means it runs the specs for each component separately from the main enroll app. This can now be run under docker by following this method.\n\n1. start the containers\n```\ndocker compose up\n```\n\n2. open a shell on the running enroll\n```\ndocker compose exec enroll bash\n```\n\n3. go to the component you want to run the specs for example financial assitance\n```\ncd components/financial_assistance\n```\n\n4. bundle install\n```\nbundle install\n```\n\n5. run the specs\n```\nbundle exec rspec\n```\n\n## Cucumber\n\nIt is possible to run cucumber, however, there are 2 drawbacks; first is that the gem webdrivers have to be removed manually and the container restarted, and the second drawback is that it uses a \"modified\" env.rb that removes all the references to the webdriver gem, this is done automatically via a virtual volume on docker compose (as end user you don't need to worry about this unless something big changes on cucumber).\n\nThese are the steps to enable cucumber \n\n1. On enroll edit the Gemfile and remove: `gem 'webdrivers', '~\u003e 3.0'`\n2. Trigger a restart for enroll with \n```\ndocker compose restart enroll\n```\n3. run cucumber\n    - from inside the container (attach a shell to the container first)\n```\nNODE_ENV=test RAILS_ENV=test bundle exec cucumber features/financial_assistance/view_eligibility.feature\n```\n - from outside the container (inside the ea_enterprise directory): \n```\ndocker compose exec -e \"RAILS_ENV=test\" enroll bundle exec cucumber features/financial_assistance/view_eligibility.feature\n\n```\n\nAfter rebuilding the container for the first time, only step 3 is needed\n\n## Common issues and how to solve them\n- rspec \n```\n  uninitialized constant Mongoid::Matchers\n```\nyou are not running the specs on test environment, run them with `RAILS_ENV=test bundle exec rspec`\n\n\n## Environment files\nDocker Compose supports image build-time and container run-time environment variables.\n\n### Build-time variables\nBy default, Compose will use a `.env` file in the project root to interpolate variables in for references (e.g.,\n`$MYVARIABLE`) in docker-compose.yml. (It will also collect some host machine environment variables for use as well,\nlike `$PWD`.) These can be referenced anywhere in docker-compose.yml, and we pass some to a given service's Dockerfile\nvia `\u003cservice\u003e.build.args` - These are picked up by Dockerfile `ARG` instructions and are used in the build. An example\nis setting image environment variables (via Dockerfile `ENV` instructions) - these variables then available in the\nbuilding image, and are also available at run time. Changes to these typically require an image rebuild. To minimize\nhost env var collisions, increase flexibility, and keep clarity of intent, it's suggested that build-time vars be\nlimited to what's needed to run a successful build.\n\n### Run-time variables\nThe docker-compose.yml uses a couple mechanisms Compose gives for setting container run-time variables\n(`\u003cservice\u003e.env_file` and `\u003cservice\u003e.environment`). The bulk of environment settings fed to Rails processes are here,\nand will require only a container restart to see a change. A common convention in this project is using files named like\n`.env.dev` to provide these run-time values (via docker-compose.yml `env_file` key). Note that new processes started in\na running container (i.e., using `docker compose exec`), will not see variable changes until that original container is\nrestarted.\n\nGenerally applicable variables are provided under the `./site` directory, as are service-specific ones - these are\nprovided default values in `env.dev.base` files. These base files typically won't need customization, but, overrides\nthat may be required can be placed in your root `.env.dev`.\n\n(Note in some case, interpolated-in build-time variables are being fed to run-time variables via `environment` entries\nin the docker-config.yml. This allows for overrides for a workflow optimization - changes to these build-time variables\ncan be seen in containers, without a rebuild.)\n\n## Advanced setup: microservices directory, and private repos\n\nDue to some customers going outside the default IC repo, ea_enterprise has a way to change the expected directory of an app, and also the ability to inject a GitHub token for private repos. This is the way to enable this\n\n1. create a file called .env in the root of the ea_enterprise directory, this will be loaded at _build time_ and the values will be used for that.\n\n### Change the directory\n\nTo change the directory of a microservice, you can use the following format\n\n```\nENROLL_DIR=enroll-dc-repo \nPOLY_DIR=dchbx-repos/polypress\nMG_DIR=dchbx-repos/medicaid_gateway\nFTI_DIR=dchbx-repos/fti\nMITC_DIR=dchbx-repos/medicaid_elegibility\nFDSH_DIR=dchbx-repos/fdsh_gateway\n```\n\n### Inject a github token\n\nTo inject a github token, add this line to the .env file\n\n```\nBUNDLE_GITHUB__COM=x-access-token:\u003ctoken\u003e\n```\n\n## Recommendations, tips and tricks\n\n- Some people complain about \"writing\" speed, and it's true, it's slow, however on the \"experimental features\", there is a new option called \"VirtioFS\" and it's fast, close to native fast, the recommendation is to enable it\n\n   - \u003cimg width=\"1090\" alt=\"Screen Shot 2022-07-15 at 1 27 05 PM\" src=\"https://user-images.githubusercontent.com/350422/179311143-090ab646-3b6d-441a-ba0b-cefc4d5de1d0.png\"\u003e\n\n- When changing env vars or other things that require a container restart, it can be useful to note that, for example,\n  you don't need to wait for the enroll web app to completely start (via `docker compose up`) to start up the rails\n  console via `docker compose exec` - once bundler is done installing gems to the container, you can likely proceed to\n  use it in a second process.\n\n- Changes to `hotpatches` files can be seen in the guest without a rebuild or a restart of the primary container process.\n  So, if you have enroll rails server running, and you have a separate rails console process running via \n  `docker compose exec`, you can just restart your rails console process and see hotpatch changes in that process.\n   \n## FAQ\n\n- how do I enter the rails console? use `docker compose exec \u003cservice_name\u003e rails c`. Or, in the Docker Desktop UI there is a button to open a terminal quickly. From there, `rails c` as normal.\n\n- why we are not executing bundle install on docker compose? \u003c- it's slower, and in theory, gems should not change that much\n\n- why the shell inside the container doesn't respond to the arrows or any other shell nicety? (usually, this happens when using the docker UI) it's because it's executing /bin/sh, you can execute /bin/bash as soon as the terminal is open\n\n## TODO\n\n- add scripts to open the console quickly \n- add scripts to run rubocop/tests\n- fix/add the Nginx in front of the services that have them on production (the one in Medicaid gateway is not fully configured yet)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fideacrew%2Fea_enterprise","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fideacrew%2Fea_enterprise","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fideacrew%2Fea_enterprise/lists"}