Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 03 17:32

    depfu[bot] on update

    (compare)

  • Dec 03 17:32
    depfu[bot] closed #594
  • Dec 03 17:32
    depfu[bot] commented #594
  • Dec 03 17:31
    depfu[bot] labeled #596
  • Dec 03 17:31
    depfu[bot] opened #596
  • Dec 03 17:31

    depfu[bot] on update

    Update rubocop to version 1.5.1 (compare)

  • Dec 03 17:24

    depfu[bot] on update

    (compare)

  • Dec 03 17:24
    depfu[bot] closed #162
  • Dec 03 17:24
    depfu[bot] commented #162
  • Dec 03 17:23
    depfu[bot] labeled #163
  • Dec 03 17:23
    depfu[bot] opened #163
  • Dec 03 17:23

    depfu[bot] on update

    Update rubocop to version 1.5.1 (compare)

  • Dec 03 17:00

    mereghost on new

    Barely working application buil… (compare)

  • Dec 02 02:47
    ianks forked
    ianks/view
  • Dec 01 22:28
    cllns commented #595
  • Dec 01 19:30
    cllns commented #1087
  • Dec 01 10:28
    famchankou starred hanami/hanami
  • Dec 01 10:09
    mcansky commented #287
  • Dec 01 10:01
    wuarmin commented #1061
  • Dec 01 10:01
    wuarmin commented #1061
Sebastjan Hribar
@sebastjan-hribar
In my routes I have only
resources :clients
resources :contact_persons
Sebastjan Hribar
@sebastjan-hribar
The entity is not updated and the params actually are not passed to the action.
Sebastjan Hribar
@sebastjan-hribar
I've tried whitelisting the params, but no luck. Any ideas how to debug it or what I'm doing wrong?
Sebastjan Hribar
@sebastjan-hribar

The params.inspect in my update action, called by the spec, returns:

#<Godmode::Controllers::ContactPersons::Update::Params:0x000055fe732aa7c0 @env={"REQUEST_METHOD"=>"GET"}, @input={}, @result=#<Dry::Validation::Result output={} errors={:id=>["is missing"], :contact_person=>["is missing"]}>, @params={}, @errors={:id=>["is missing"], :contact_person=>["is missing"]}>

It confirms nothing gets to the action, but why is the request method GET?

Sebastjan Hribar
@sebastjan-hribar
Also, create, show and index all work fine.
Paweł Świątkowski
@katafrakt
@sebastjan-hribar I would start with adding some validation and checking if it passes for params
You say params are not passed to the action. Then how does the code that leads to execution of this action looks? Also what is in Godmode::Action?
Sebastjan Hribar
@sebastjan-hribar
@katafrakt Hi, here's a gist of the relevant code. I've followed same patterns as in my previous app, the main difference being is that here are many apps (Godmode being one of them) under the main project tmsr. The other app only has the webapp.
https://gist.github.com/sebastjan-hribar/76bcd650c01837f67ffb143e3470d839
Paweł Świątkowski
@katafrakt
@sebastjan-hribar form_for :contact_person, routes.contact_persons_path(id: contact_person.id) - why contact_persons_path and not contact_person_path? You're probably calling different action (create perhaps?). Or I don't understand your routing ;)
Kai Kuchenbecker
@kaikuchn

Generally what my AJAX requests do is either return a failure or success. If it’s a failure I simply use JS to display a notification. Upon success however, I generally display a notification and also re-render a section of the page, ususally by assigning the contents of a partial to a JSON object and then replacing the page section with JS.

I thought as much. If that is how you want to handle things, then you will have to make sure that you don't pass the request params to the rendering of the partial, just replace it with an empty hash I guess.

@smarthouseprojectdotorg Yes, this is the right place. Welcome to Hanami!
As Sebastjan pointed out all gives you a result set, which is all records in your repository. If you have a look at the guides you will find out WHY you cannot chain methods. This is intentional! In general I recommend perusal of the guides since Hanami is different from what, say, a Rails Developer is used to.
Sebastjan Hribar
@sebastjan-hribar
@katafrakt I knew it has to be something stupid I did and you found it :smile: Thank you!
Works like a charm now
smarthouseprojectdotorg
@smarthouseprojectdotorg
@sebastjan-hribar @kaikuchn
Thank you! So using where() or where{} gives the result set right away and then I can use it or say .delete it. Does it sound correct?
Danny Santos
@DannySantos

@kaikuchn That’s one of two ideas we’ve been working with. We implemented it as a view method on :js views:

def params
  return @_params if @_params

  @_params = locals[:params].dup
  @_params.to_h.keys.each{ |k| @_params.to_h.delete(k) }
  @_params
end

The other idea we’re playing with is adding an option to the form_for method which tells it not to prioritise the params. There’s a discussion about it going on in this issue if anyone is interested:

hanami/helpers#149

smarthouseprojectdotorg
@smarthouseprojectdotorg

Asked the below in the forum but it seems this chat works better!
I saw a discussion about mounting an app to a domain and that followed with an update but it seems to not work with a subdomain as stated in the docs. It only works if I specify a full domain name. Is it expected or a bug? My workaround is to put a domain name to env and fetch it from ENV in environment.rb but that would not be needed to do if mounting worked with a subdomain name.

This does not work (order DOES matter but it’s not a problem, yet took time to realize it!):

mount MyApp1::Application, host: ‘app1’, at: ‘/’
mount MyApp2::Application, at: ‘/app2’
mount Web::Application, at: ‘/’

This works:

mount MyApp1::Application, host: ‘app1.domain.com’, at: ‘/’
mount MyApp2::Application, at: ‘/app2’
mount Web::Application, at: ‘/’

A workaround:

mount MyApp1::Application, host: ENV.fetch(‘MY_DOMAIN_NAME’), at: ‘/’
mount MyApp2::Application, at: ‘/app2’
mount Web::Application, at: ‘/’

The domain name differs for development, production and also my local development hence the question. Thank you!

Kai Kuchenbecker
@kaikuchn
@smarthouseprojectdotorg hanami/router#104 is the PR that implemented the feature. It wasn't touched since (at least that I can tell). I'd therefore say that the docs are wrong.
Surya Poojary
@suryapoojary-x
Guys I don't know Rspec or BDD
Can I still start with hanami
Sebastjan Hribar
@sebastjan-hribar
@poojx I use minitest myself. Just specify it when creating a new project: https://guides.hanamirb.org/command-line/project/#testing-framework
Sebastjan Hribar
@sebastjan-hribar
A word of caution, yesterday I had to recreate my gemfile.lock and the updates seem to affect pluralization of contact_person. I created the table contact_persons, but the now broken tests complain about not finding contact_people :smile: I'm aware of this plural form, however it doesn't seem natural for this context. Anyway, I'm changing it to simply contacts what I should have done in the first place.
Sebastjan Hribar
@sebastjan-hribar
Auto generated tests for minitest report deprecated warning for global use of must_equal and global use of must_include which will fail in Minitest 6. I'm using the latest version 5.13.0. Where should I check if this is already being reported?
Kai Kuchenbecker
@kaikuchn
I think here https://github.com/hanami/hanami/issues would be appropriate
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