Auto-merge update PRs for DAQ services

[callumforrester]

We should automatically merge updates (and later automatically run system tests on those updates) to blueapi, nexus writer et al. raised by dependabot (later renovate). Bringing us closer to a continuous deployment scenario.

[callumforrester]

@DiamondJoseph @ZohebShaikh opinions welcome

[DiamondJoseph]

Agreed for patch/minor updates, helps keep us honest on versioning too.

[gilesknap]

I would also like to do this for IOCs.

Some considerations:

• this would include auto merge of updates to services-template-helm (which affects IOCs mainly)
• I would like to be able to make beta tags on dependencies so I can test them without them causing an auto update - only non beta tags should trigger a merge - @DiamondJoseph I assume we can we do that?
• system tests that move motors might not be a bit risky - what kind of system tests can we do?

[ZohebShaikh]

We should review the existing Alertmanager alerts to make sure they’re useful and sending emails to the daq-core team.

For system tests, running them should be as easy as clicking a button—we should aim to simplify the process to that level. One idea is a pytest pod with all the tests that we can trigger on demand. If we automate this, we also need to make sure it doesn’t risk damaging the hardware.

[DiamondJoseph]

* this would include auto merge of updates to services-template-helm (which affects IOCs mainly)

We're all happy for all dependencies in this repository to get automatically merged on minor and patch versions, which makes the packageRules simpler so happy with that.

* I would like to be able to make beta tags on dependencies so I can test them without them causing an auto update - only non beta tags should trigger a merge - [@DiamondJoseph](https://github.com/DiamondJoseph) I assume we can we do that?

This is the default behaviour, so if we leave allowUnstable off, that should always keep us on the latest release unless we've manually switched to a pre-release, then it will remain there (AFAIK)

• System tests

DAQ are manually running system tests every sprint, but I would also love something automated

[DiamondJoseph]

Reopening because:

• blueapi is <1.0.0 so all changes are ignored
• IOCs are not using semantic versioning, so the major should be allowed

We should remove the conditions on <1.0.0 not being merged and allow for major changes to be merged. This will become slightly less reliable to "eating our dogfood"

[gilesknap]

@DiamondJoseph should we switch to semantic versioning for IOCs? It is not a direct fit but not out of the question.

[DiamondJoseph]

@gilesknap if we're aiming for automating pushing updates it's a way of giving some confidence to it. 2025.5.1 and 2025.5.2 may be entirely incompatible with one another, where 2033.12.1 may be completely compatible with 2011.1.1 I don't know what goes into a different version of an IOC though, can we talk it through tomorrow on a call?

[gilesknap]

Sure. Semantic versioning does not have a great deal of meaning for IOCs because they are based upon multiple support modules which don't particularly implement semantic versioning. That is why we chose dateVer.

It would be a moderately significant change for us to switch to semVer (e.g. lots of docs need updating!). Plus it would rely on a discipline for controls engineers that is not currently a job requirement.

Essentially we would normally assume that any time an IOC gets a tag that it is a working version that we want to deploy.

I think from this conversation we can't have IOCs using one renovate update rule re version and blueapi using another?

Let me know if you want to discuss in person, I'm around until 3PM today.

[DiamondJoseph]

@gilesknap we can configure these packageRules however we like:
so long as we're consistent in some way of marking the packages we can have one rule that only allows minor/patch and one that allows all. e.g. we can now have minor/patch for non-ioc version >=1.0.0, patch for non-ioc version <=1.0.0, all for iocs

[gilesknap]

OK I think then we should stick to datever for IOCs and always deploy a new tag.