https://www.puppet.com/community logo
Join Slack
Powered by
# voxpupuli
  • y
    now I should understand what is the dialect I should write the spec in.. as beaker vs beaker-spec is confusing.. I was expecting beaker is execution and provisioning tool which runs the rspec (with beaker-rspec) for the acceptance test.. but it seems those are different dialects of rspec 🤔
  • b
    check https://serverspec.org/ for all the matchers
  • b
    and I never really tried to "learn" rspec/the dialect. My knowledge grew through reading existing tests and poking ewoud and @Alex Fisher
  • y
    I learned the rspec-puppet in the same way (by poking nearest puppet master while ago)
  • y
    shall I use 
    voxpupuli-acceptance
    helpers? or not really needed?
  • y
    shall I use 
    voxpupuli-acceptance
    helpers? or not really needed?
  • b
    we use them and they are fine. I don't see a reason not to use them
  • y
    then I can use rake task instead of calling beaker it seems.. well, let me try this way
  • m
    @bastelfreak wee bit of more info, on our facterdb discussion, the use case is to use the returned facts to ensure a package selector in the code selects a package specific for RHEL Minor version.
  • m
    is this usecase you would consider if i where to raise a request to the gems to consider OS minor versions?
  • m
    my thoughts are perhaps this would be something better tested in acceptance
  • m
    and not in unit
  • b
    agreed. I would test that with an acceptance test or mock the fact in a unit test. But if someone want's to implement support in facterdb for that, I would be fine with it.
  • m
    ok ill discuss and see if anyone in CAT can spare some time to make such a change, probably in rspect-puppet-facts, facterdb would just need some data files properly named correct?
  • b
    it probably needs some logic adjustments because it assumes something like os-arch-major.json I think
  • b
    also does metadata.json even support minor versions in the schema? or doesn't the customer want to use that
  • b
    a spec test can also do an explicit lookup in facterdb, you don't have to iterate on everything in metadata.json
  • m
    the majorversionfeild in metadata.json looked into this yesterday, its just a string to “do what makes sense for your OS”
  • y
    Yay! beaker works for me! 🎉
  • y
    Yay! beaker works for me! 🎉
  • y
    I was able to run the acceptance test on my M1 (with docker HV which is emulated by podman running in a lima-vm)!
    Copy code
    BEAKER_setfile=ubuntu2004-AARCH64 pdk bundle exec rake beaker
  • y
    time to write it down somewhere..
  • b
    @Yury Bushmelev maybe a conference talk? :)
    đź‘Ť 1
  • b
    it would be awesome id you could wrire a small blogpost for voxpupuli.org or enhance the voxpupuli-acceptance readme.md with the steps you took to enable it
  • y
    I’m considering it 🙂
  • y
    hm.. beaker specs are not using 
    context
    🤔 is it intentional? or just happens this way?
  • y
    in puppet rspec it’s usually one 
    describe
    per manifest and multiple 
    context
    blocks inside which changes the resource behaviour
  • m
    @bastelfreak this may be going too far back to camptocamp ownership, but anyideas why openbsd gets special treatment in rspec-puppet-facts, it looks like this commit https://github.com/voxpupuli/rspec-puppet-facts/commit/a4c93806d9b911b2af28727af1cf7ab647e1af99 was what put in the default of “major version only” but there was logic to leave out openbsd, looks like openbsd will map whole release name not just majpr version
  • m
    also it looks like i could just copy this code for a RHEL exception
  • m
    i think facterdb just needs the files, its just the OS iterator here that needs a tweak
1...217218219...648Latest