feat(actions): switch to upstream CI templates

[laugmanuel]

• drop tests for Foreman <= 3.5 (as it does not support the template)
• switch generic rubocop for theforeman-rubocop
• fix rubocop warnings

[laugmanuel]

@archanaserver what's the recommended way of defining specific version of other plugins as dependencies?
In this case we need foreman-tasks. However, the generic action uses the latest version of the plugin which breaks on older Foreman versions (3.7 and 3.8) as the plugin defines a minimum foreman version.

[laugmanuel]

@archanaserver what's the recommended way of defining specific version of other plugins as dependencies? In this case we need foreman-tasks. However, the generic action uses the latest version of the plugin which breaks on older Foreman versions (3.7 and 3.8) as the plugin defines a minimum foreman version.

I guess this would require seperate branches for the targeted foreman versions. WDYT @kamils-iRonin ?

[archanaserver]

@archanaserver what's the recommended way of defining specific version of other plugins as dependencies? In this case we need foreman-tasks. However, the generic action uses the latest version of the plugin which breaks on older Foreman versions (3.7 and 3.8) as the plugin defines a minimum foreman version.

I guess this would require seperate branches for the targeted foreman versions. WDYT @kamils-iRonin ?

Thank you for raising this point about managing plugin versions. While foreman_plugin.yml itself doesn't have any mechanism for specifying exact plugin versions, I guess either we can introduce optional input (foreman_tasks_version) to accept the desired version or another way you mentioned about creating separate branches for older Foreman versions.

I believe in terms of flexibility the first one would be more flexible, and another would be easier to do it here. What are your thoughts on this, @ekohl? Do you have any specific concerns or preferences regarding these approaches?

[ekohl]

It's a good question I didn't consider before.

Essentially you want to specify versions and let bundler handle it. We support bundler.d for plugins (https://github.com/theforeman/actions/blob/fc8754939ee6eb01be4be973fc0a588365adf8c4/.github/workflows/foreman_plugin.yml#L104-L106) and you could write up some code there. I don't think we reliably export the Foreman version in some way, but we could (by reading $foreman_checkout/VERSION and setting that as an environment variable). Then you could use that in the Gemfile to implement some logic.

Would that make sense?

[laugmanuel]

So far we didn't need to maintain different plugin branches as the plugins were compatible with basically all recent foreman versions and we just dropped support as a whole once a breaking change was introduced.

It would be nice to keep it this way so development stays simple (without the need for backporting/cherry picking and so on).

Having the Foreman versions available would make it easier. Couldn't we just use the branch name of foreman itself to get exported? We define the versions we want to test in the Workflow anyway.

[ekohl]

Having the Foreman versions available would make it easier. Couldn't we just use the branch name of foreman itself to get exported? We define the versions we want to test in the Workflow anyway.

I don't want that to be the interface, because we also test out PRs this way. Random example is theforeman/foreman_ansible#693

[laugmanuel]

Having the Foreman versions available would make it easier. Couldn't we just use the branch name of foreman itself to get exported? We define the versions we want to test in the Workflow anyway.

I don't want that to be the interface, because we also test out PRs this way. Random example is theforeman/foreman_ansible#693

Understandable. What about a more open interface where the caller can pass in arbitrary variables which are exposed in the job?

[ekohl]

I like the idea of setting arbitrary (environment) variables for specific versions. Perhaps we can track this in an issue on https://github.com/theforeman/actions and gather some broader feedback? I can imagine other plugin authors may also have feedback.