So I spun up a box here, and could reproduce it.
The problem seems to be that while our tests execute hammer host update --puppet-class-ids $id --name $(hostname -f), the values are correct and hammer answers Host updated., the puppet class is not actually assigned.
Assigning the class in the WebUI or via the API (curl -XPUT -d'{"host":{"puppetclass_ids":[1]}}' -H 'Content-Type: application/json' -u admin:changeme -k https://localhost/api/hosts/1) seems to work fine, and a Puppet run afterwards does apply the motd module.
And indeed, if you run hammer --debug with the above parameters, the resulting update call is actually empty:
[ INFO 2021-07-22T08:41:35 HammerCLIForeman::Host::UpdateCommand] Called with options: {"option_puppetclass_ids"=>[1], "option_volume_list"=>[], "option_interface_list"=>[], "option_name"=>"pipe-foreman-server-nightly-centos7.yatsu.example.com", "option_id"=>1}
[DEBUG 2021-07-22T08:41:35 HammerCLIForeman::CommandExtensions::UpdateCommon] Called block for HammerCLIForeman::UpdateCommand request params:
#<Proc:0x00000000027d84b0 /opt/theforeman/tfm/root/usr/share/gems/gems/hammer_cli_foreman-2.6.0.pre.develop/lib/hammer_cli_foreman/command_extensions/update_common.rb:8>
[ INFO 2021-07-22T08:41:35 API] Server: https://pipe-foreman-server-nightly-centos7.yatsu.example.com
[ INFO 2021-07-22T08:41:35 API] PUT /api/hosts/1
[DEBUG 2021-07-22T08:41:35 API] Params: {
"host" => {
"name" => "pipe-foreman-server-nightly-centos7.yatsu.example.com"
}
}
I don’t know hammer well enough to understand why it stopped translating this, but maybe someone wiser than me can chime in here.
FWIW, I did find GitHub - theforeman/hammer-cli-foreman-puppet but didn’t manage to install it on a nightly box, as the commands clash with the ones from hammer_cli_foreman and I really have no clue how to make them not clash.