Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 00:27
    timriley synchronize #1040
  • 00:27

    timriley on application-views

    Generalize param name (compare)

  • 00:27
    timriley synchronize #1040
  • 00:27

    timriley on application-views

    Remove unneeded pathname require (compare)

  • 00:23
    timriley synchronize #1040
  • 00:23

    timriley on application-views

    Add hanami-view as a runtime dep (compare)

  • 00:15

    timriley on support-nil-layouts_dir

    Bump version (compare)

  • 00:13
    timriley synchronize #1040
  • 00:13

    timriley on application-views

    Switch to an extension of Hanam… (compare)

  • 00:02
    timriley synchronize #1040
  • 00:02

    timriley on application-views

    Switch to an extension of Hanam… (compare)

  • Apr 08 23:26
    timriley synchronize #1040
  • Apr 08 23:26

    timriley on application-views

    Switch to an extension of Hanam… (compare)

  • Apr 08 06:15
    0mechanic starred hanami/hanami
  • Apr 07 15:08
    jodosha labeled #1041
  • Apr 07 15:08
    jodosha assigned #1041
  • Apr 07 15:08
    jodosha milestoned #1041
  • Apr 07 15:08
    jodosha opened #1041
  • Apr 07 15:07

    jodosha on travis-integration-matrix

    Travis CI integration matrix (compare)

  • Apr 07 15:02

    jodosha on point-to-hanami-view-1.x-master

    (compare)

Jeff Dickey
@jdickey
Hey, folks: has anyone successfully used Semaphore CI to build a Dockerised Hanami app? I'm running into a database-access problem that has me profoundly confused
Kai Kuchenbecker
@kaikuchn
No, I'm using CircleCI. However, I may still be able to help you out
Jeff Dickey
@jdickey

Thanks, @kaikuchn. I'm having a problem getting Semaphore's Postgres service to connect with my app (which has already passed non-Docker tests) using their standard Postgres service, which is activated by the command step sem-service start postgres. The CI log indicates that it starts successfully, and a subsequent sem-service status postgres confirms this. Their (Rails+Postgres) doc at https://docs.semaphoreci.com/article/73-ruby#database-configuration indicates that setting the DATABASE_URL environment variable in the Dockerfile (which Hanami also uses for the same purpose, in the same format) to, e.g., postgresql://postgres:@0.0.0.0/semaphore_hanami_poc should Just Work. However, running bin/hanami db drop acts as though Postgres isn't running.

From the log:

Step 11/15 : RUN bin/hanami db drop || true

 ---> Running in 291c9f4b9efb

dropdb: could not connect to database template1: could not connect to server: Connection refused

        Is the server running on host "0.0.0.0" and accepting

        TCP/IP connections on port 5432?

/usr/local/bundle/gems/hanami-model-1.3.1/lib/hanami/model/migrator/postgres_adapter.rb:99:in `block in call_db_command'

        /usr/local/lib/ruby/2.6.0/open3.rb:219:in `popen_run'

        /usr/local/lib/ruby/2.6.0/open3.rb:101:in `popen3'

        /usr/local/bundle/gems/hanami-model-1.3.1/lib/hanami/model/migrator/postgres_adapter.rb:98:in `call_db_command'

        /usr/local/bundle/gems/hanami-model-1.3.1/lib/hanami/model/migrator/postgres_adapter.rb:44:in `drop'

        /usr/local/bundle/gems/hanami-model-1.3.1/lib/hanami/model/migrator.rb:295:in `drop'

        /usr/local/bundle/gems/hanami-model-1.3.1/lib/hanami/model/migrator.rb:76:in `drop'

        /usr/local/bundle/gems/hanami-1.3.2/lib/hanami/cli/commands/db/drop.rb:26:in `drop_database'

        /usr/local/bundle/gems/hanami-1.3.2/lib/hanami/cli/commands/db/drop.rb:17:in `call'

        /usr/local/bundle/gems/hanami-1.3.2/lib/hanami/cli/commands/command.rb:85:in `call'

        /usr/local/bundle/gems/hanami-cli-0.3.1/lib/hanami/cli.rb:57:in `call'

        /usr/local/bundle/gems/hanami-1.3.2/bin/hanami:6:in `<top (required)>'

        bin/hanami:29:in `load'

        bin/hanami:29:in `<main>'

The Dockerfile continues on to the next step (because we ORed true with the previous one), and encounters the identical error when it attempts to run bin/hanami db create

Ideas?

Kai Kuchenbecker
@kaikuchn
In their example on managing databases they don't actually connect to the DB from within another container but from within the same "command" which I assume is run in a container.
They also say that services are local to such a block... Can you maybe show the relevant part of the semaphore config file?
Is maybe this the workflow you want to have? (I.e., instead of using sem-services start and link containers)
Jeff Dickey
@jdickey
@kaikuchn I've put the two pipeline configs up at https://gist.github.com/jdickey/0bd4113e018befb97d62bf7db369bb5b
  • docker-build.yml is the one that's failing; it runs after semaphore.yml;
  • semaphore.yml runs CI tests against a non-Dockerised copy of the app
Kai Kuchenbecker
@kaikuchn
So you try to setup the database when building the Docker image. Is that right?
Also, I don't see you specifying the DATABASE_URL in the docker-build.yml?
Jeff Dickey
@jdickey
Yes; before I started using Semaphore, I'd built images locally using a close variant of the current Dockerfile and had essentially followed the docs for setting up DATABASE_URL and the other variables in the .env files
No, it's in the Dockerfile, which really should be in that Gist. Hang on and I'll add it
Updated; Gist ordering means it's now the second file in the Gist
Kai Kuchenbecker
@kaikuchn
Why aren't you preparing the DB when starting the container instead of when building it?
The DB isn't part of the image, so there's no use of running it during build time unless you're never leaving that context (i.e., you build where you run).
Jeff Dickey
@jdickey
Good question; I don't really have an answer for that beyond "it worked the first time (locally)"
Kai Kuchenbecker
@kaikuchn
Yeah, because it's the same context. But you really should write an entrypoint.sh script instead and do that there.
Jeff Dickey
@jdickey
true, it's not part of the image (and d'oh!). Yeah, and entrypoint.sh makes sense; always be learning. Thanks; I think I've got enough ammo for the next footgun :D
Kai Kuchenbecker
@kaikuchn
Here's a basic one:
#!/bin/bash

set -Eeuo pipefail

# do stuff

exec "$@"
Jeff Dickey
@jdickey
right; I'll figure out the 'do stuff'. Thanks again
Kai Kuchenbecker
@kaikuchn
That's basically line 21 and 22 in your dockerfile.
don't forget to add ENTRYPOINT ["/docker-entrypoint.sh"] after adding the script. Otherwise he'll just execute command without passing it to your script.
I guess I'd then add a different step to your pipeline (i.e., another yml file?) where you use the built image to run your tests, or whatever you wanted to do, by specifying it in the containers section.
Jeff Dickey
@jdickey
Right; that's in the plan but I was just trying to recreate my deploy-to-k8s-from-locally-built-crap flow first. Running staging-level tests is in the plan. I'm almost getting buyers' remorse from taking on all this docker+k8s+dog-knows-what for a small team; we're not Google scale, but we have had problems matching environments when hand-deploying
there's a ginormous market opportunity for whoever finds the sensible middle ground on this
Kai Kuchenbecker
@kaikuchn
Yeah, I feel ya. k8s is awesome once everythings running. But getting there in a reproducible manner takes time.
Jeff Dickey
@jdickey
I first learned CI/CD when I was part of a large-ish company (150+ devs, 50+ dedicated ops people) and we had single-button deploys; I just misunderestimated how much work it took for one or two folks to get there
Thanks again
Kai Kuchenbecker
@kaikuchn
Oh one other thing you could try is adding --network bridge to the docker build call.

The docker docs are a little thin on this flag.. API 1.25 says

Sets the networking mode for the run commands during build. Supported standard values are: bridge, host, none, and container:<name|id>. Any other value is taken as a custom network's name to which this container should connect to.

docker build --help says

--network string Set the networking mode for the RUN instructions during build (default "default")

Jeff Dickey
@jdickey
yeah, that makes sense, too, and it's a cheap thrill. But I thought bridge was the default
Kai Kuchenbecker
@kaikuchn
So maybe bridge which I'd have thought was the default, isn't?
Jeff Dickey
@jdickey
oops; nope; I'll give it a try
Kai Kuchenbecker
@kaikuchn
My guess is that the docs are wrong and bridge is actually the default..
Otherwise how can you pull packages etc?
A sanity check I like to perform when I cannot establish a connection is this:
service="0.0.0.0/5432"; (timeout 1 bash -c "cat < /dev/null > /dev/tcp/$service" && echo "Success opening remote port") || echo "Could not connect"
This just checks whether a port is open without needing to install special networking tools.
Jeff Dickey
@jdickey
Right; that's a good one. I'll swipe that :grinning:
Sebastjan Hribar
@sebastjan-hribar

We're currently setting up the internationalization project wide and I found these resources: https://www.bounga.org/ruby/2016/10/08/using-i18n-with-hanami/ and https://github.com/ippachi/hanami-i18n

Since there is still no updates hanami/hanami#610 we'll go with the above gem. Can we tie the locale to a setting entity so admins could change the locale per each end user company?

Jeff Dickey
@jdickey
@kaikuchn Well, --network bridge had no discernible effect; on to the entrypoint
Kai Kuchenbecker
@kaikuchn
@jdickey who knows how semaphore makes the service available to you, probably service endpoints just aren't accessible for the docker daemon.. So entrypoint is a good way to just not fight that particular battle.
Jeff Dickey
@jdickey
Makes sense; I'll give it a try and ping their support if I don't get it in a day or so. Thanks for all your help
Kai Kuchenbecker
@kaikuchn
Good luck. Always happy to help.
Paweł Świątkowski
@katafrakt
@sebastjan-hribar I guess you need to set appropriate I18n.locale = locale_from_setting before every action, but it's definitely doable.
kristjan-brezovnik
@kristjan-brezovnik
Hi! I'm completely new to Hanami and basically only style the frontend. To that effect, I would like to use the LESS preprocessor. I've looked though the manuals, but can't seem to figure out what exactly I'm doing wrong. In my 'app/testapp' folder I have downloaded the 'less.js' file and put it under 'assets/javascripts' and in my 'styles.css.less' stylesheet (under 'assets/stylesheets') I put a very simple #header{font-weight: bolder;} declaration to test it. I've also added <link rel="stylesheet/less" type="text/css" href="styles.css.less" /> and <script src="less.js"></script> tags to the app's 'application.html.erb' file. The style is not applied, so now I'm a bit lost. Anyone have any experience with LESS or can point me in the right direction? I could work with SASS or SCSS, if it's easier.
Sebastjan Hribar
@sebastjan-hribar
@katafrakt thank you, will try that. Will have to rethink the use case though if it's worth implementing, since it would effectively not be changed often is at all for one end user. Might as well make the config before deploy.
Sebastjan Hribar
@sebastjan-hribar
@katafrakt On a second note if we setup an AJAX call to a language selector on the UI then users could also make adhoc locale changes, provided we set locale before each action.
Ivan Rubanovskiy
@xvonabur
Hi! Does Hanami supports composite keys in hanami-model? I saw old issue on GitHub, but it's 2 years old: hanami/model#432
Kai Kuchenbecker
@kaikuchn
Folks, I just learned that Ruby 2.7 preview has Enumerator.produce and I'm loving it. Why isn't there more noise about this absolutely fantastic (experimental) addition to Ruby? Check it out
With this I'll never have to write a while loop again x)
Matt
@matt-from-toronto
i just took a look through the guide, hanami looks frickin awesome. congrats all! really love how repositories and entities are separated (i hate models in rails), and love the interactors concept too, callbacks have been very painful for me to work with