Fixes #37942 - Adding Ansible Check Mode to Ansible Job Templates

[bnerickson]

Overview of Changes

This PR intends to add the Ansible Check Mode (identified with the --check argument to ansible-runner) to Ansible Job Templates via a checkbox option. The follow-up after all the subsequent PRs are submitted/approved (hammer cli support for instance) is to add Ansible Diff Mode support in a similar manner. See below screenshot:

Implementation Considerations

Foreman already offers the ability for users to run Ansible Config Commands (Running Ansible Roles on a host) with check mode enabled by setting the host's host parameter ansible_roles_check_mode to True. This is left in-place as-is. However, that implementation does not allow users to run Ansible Playbook jobs or any other custom remote execution jobs in Ansible Check Mode. Nor is setting a host parameter as flexible as setting an entire Job Template to use Ansible Check Mode.

I have a few questions/concerns:

1. It's sort of kludgy, but I've added a separate "job_check_mode" variable passed to the smart_proxy_ansible plugin instead of using the existing "check_mode" variable. My reason for doing this is that the latter is used when setting the ansible_roles_check_mode host parameter which is only intended for use when running an Ansible Roles job. Meanwhile, this PR is intended for use on any host that is the target of any job whose template uses the new Ansible Check Mode (identified by the "job_check_mode" variable). Another reason I split the functions in two is that I do not want to break the existing functionality. Because of this change, "check_mode" with the ansible_roles_check_mode parameter will not work for rex (remote execution) jobs. This obviously runs completely counter to what I'm trying to accomplish in this PR.
2. For the db/migrate/20241022000000_add_ansible_check_mode_to_templates.rb file, I arbitrarily set the date string in the filename to 20241022000000, but is that supposed to be automatically generated somehow?

Testing Steps

1. Add the changes in Fixes #37942 - Add job_check_mode to allow Ansible Check Mode in Job Templates smart_proxy_ansible#94 to your test environment.
2. Add the changes in this PR to your test environment.
3. Clone the "Ansible Roles - Ansible Default" Job Template.
4. In the clone's "Ansible" tab, select the "Ansible Check Mode Enabled" checkbox and save the Job Template.
5. On a host, schedule a Job and select the cloned Job Category and Job Template. Execute the job.

Checklists

• I am familiar with the contributing guidelines.
• I have added relevant tests for my changes.
• I have updated the documentation accordingly.

Additional Notes

This PR is not dependent on any other changes. The follow PRs are dependent on this change:

• hammer-cli PR: Fixes #37942 - Adding ansible_check_mode option to Hammer Job Template Commands hammer-cli-foreman-ansible#31
• smart_proxy_ansible PR: Fixes #37942 - Add job_check_mode to allow Ansible Check Mode in Job Templates smart_proxy_ansible#94
• Documentation update PR: Fixes #37942 - Updating Job Template Documentation with Ansible Check Mode Option foreman-documentation#3391

[adamruzicka]

Would it also make sense to have this on the job level?

[bnerickson]

Would it also make sense to have this on the job level?

Agreed! It'd be great if this were also available on a job-based level. I might tackle that after job templates are working. I don't know where to start there yet.

[maximiliankolb]

cc @Thorben-D

[nofaralfasi]

I'm currently facing some issues with my local environment, so I'll need to delay testing until they're resolved. In the meantime, to answer your question:

For the db/migrate/20241022000000_add_ansible_check_mode_to_templates.rb file, I arbitrarily set the date string in the filename to 20241022000000, but is that supposed to be automatically generated somehow?

Yes. If you run the Rails generator command to create a migration (rails generate migration), Rails automatically prefixes the migration file name with the appropriate timestamp.
As long as the timestamp doesn't conflict with existing migration timestamps, it's fine to proceed with the manually set value.

[nofaralfasi]

This is no longer needed. See:

foreman_ansible/.rubocop_todo.yml

Lines 160 to 161 in a6f5ac9

	Style/FrozenStringLiteralComment:
	Enabled: false

[nofaralfasi]

Could you update the Rails version to 7.0 or higher?

[nofaralfasi]

Since the default value is already set to false, there's no need to update these templates again.