Automatically setting Fixed in release on PR merge

Hello everyone,

You may remember PR Processor Next Generation. I’ve been working on automating some annoying work that’s easy to forget:

The PR includes some refactoring I had to do to keep it clean, but the commits are separated into logical chunks. The short summary is:

  • Only acts on merged PRs to a master or develop branch. There is no handling for stable branches.
  • The app is currently only installed for The Foreman · GitHub and not Katello Project · GitHub (on my TODO list)
  • Only Fixes #xyz issues are gathered. Refs #xyz is ignored
  • Only if there’s a project configured, it’s applied
  • The fixed-in-release is automatically determined by the highest open version (sorted by version number)

I’d like to roll this out soon. Probably Wednesday so I have time to monitor the deployment.


I suppose we’ll need to be mainly careful after branching. For everything we’ll cherrypick to the stable branch, we’ll need to modify fixed in version. How does it deal with something, that already has some version set?

Thanks @ekohl, looking forward to see this in action.

My initial thought was to derive the version from the branch name (1.22-stable -> find the next open 1.22.z) but first we want to focus on the main workflow which will save the most time.

I wouldn’t mind automating this at a later stage but there’s a difference between Katello and Foreman workflows. Katello saves up all cherry picks and does a bulk PR before release where Foreman picks all the time and then does a release. Because of these differences @tbrisker convinced me to split the effort and first release this.

It’s written to be careful. So it first retrieves the versions. If the intended version is missing, it’s added. I’m sure there’s a race condition between the retrieval and storing, but I think it’s unlikely we’ll hit this.


I would love to see theese processes formalized and maintained somewhere. I do not have enough experience how to do so for being really helpful, but some graphviz, or even just an process chart would be nice to have.

Anyway, I love automating that :+1: I feel this really necessary as some maintainers easily forget (for example @ezr-ondrej is really slopy one! :sweat_smile:)

Great feature, thanks @ekohl!
Does being installed for theforeman mean it will work on all repos in th org?
What are the prereqs for the script to work? Is existing correct and open version in Redmine enough?

For Hammer project in Redmine we use different versions for hammer-cli and hammer-cli-foreman. Could it be possible to set mapping between github repo and the specific version set?


It only works on projects which have a Redmine project set in the config. For example, Hammer is configured this way:

However, I now see that hammer-cli-foreman uses the same project but prefixes the version: (Roadmap - Hammer CLI - Foreman). This is where my script would currently likely fail. LooseVersion('hammer-cli-0.18.0') < LooseVersion('hammer-cli-foreman-0.18.0') raises a TypeError.

I can see a redmine_version_prefix setting where we strip away the prefix. Then see if it starts with a number. Only then do we consider it a valid version to compare. I think then this would work for the Hammer usecase.

Thanks for making me look at other use cases that would have broken otherwise :slight_smile:

1 Like

Going over the projects I see two cases that are not standard:

  • Discovery uses Discovery Plugin Next which would not be recognized. Easiest workaround would be if it was renamed to Discovery Plugin 1.NEXT or used an explicit 1.16.0 for the next minor like others do. @lzap?
  • Remote execution has foreman_remote_execution x.y.z and foreman_remote_execution_core x.y.z. I wouldn’t know which to pick. I can either configure it to one of the two or a non-existing prefix to disable it. @inecas / @aruzicka?

Great! That sounds like a plan. Let me know if you need any help with that. Thank you for providing the tool also for plugins.

The alternative was to create Redmine sub-projects but that might be a lot of work and only confuse end users who want to create a bug report.

I’ve added a commit, but for now it’s untested. Unless there are objections I’ll roll this out tomorrow and monitor the logs for issues. A message will be posted here when it’s live. Then I’d ask maintainers to watch for any incorrect Fixed-in-release values.

1 Like

This is now live. Bug #27317: Sync template for playing roles with new inventry structure - Foreman was my test case. I’ll be monitoring but I’d ask maintainers to monitor their projects as well.

1 Like

Of course I can change that, the idea behind this was that I am very strict about semantic versioning (or at least I try to), so I actually don’t know if the next discovery is gonna be 16.0 or 15.1 because this depends on core changes. So I guess I will simply set 15.1.0 for now and if it turns out to be 16.0 just renaming should do it and no further action is needed because 16 > 15.1. Not sure if this would cause any pains for rel-eng process tho, in that case I’d need to mass reassign fixed in version 15.1 issues to 16.0. Can do manually, not a big deal.

I changed it. Hope that Discovery Image and Discovery Plugin version scheme is not causing you any issues. In the worst case we could create new project for FDI.

There are bulk edit tools in Redmine. You can select items with shift and control. Then right click:

Then you can either change a single attribute or multiple via the edit link. You can use this to change version.

1 Like

Looks like there isn’t support for fixed in version from the bulk edit, which kind of makes sense since issues can have multiple fixed in version. I think renaming a version oth should be pretty easy from the project settings page.

In this cases, I would recommend to primary use the foreman_remote_execution - even when core gets update, it usually is released with new foreman_remote_execution and provided (I assume), it can be changed manually later, it’s good enough solution IMO