Openhab-addons: Handling of Pull Requests

[kaikreuzer]

Note: Changes to pull request processing due to openHAB 3.x development

As you might be aware, the core classes of openHAB have changed their namespace from org.eclipse.smarthome to org.openhab with https://github.com/openhab/openhab-core/pull/1294.
In consequence, none existing add-ons compile against this code anymore and thus have been removed with https://github.com/openhab/openhab-addons/pull/6701 from the master branch (from which version 3.0.0 is built).

Since we have many open PRs in this repo and most of them are applicable and interesting for existing 2.5 users, we have created a new branch 2.5.x and made this the default of the repo, meaning that new PRs are automatically created against it. All existing PRs should be manually changed to go against this branch and also be rebased on it to avoid merge conflicts. We plan to release 2.5.x updates of add-ons on a regular basis, so that those fixes will be made available to existing users without having to wait for a 3.0 release.

IMPORTANT: PRs on the 2.5.x must be backward compatible and not break existing setups - when they are released, they are replacing previous 2.5.0 versions of the add-ons, so please take special care that nothing breaks!
If you are working on a major rehaul or a new add-on that you do not want to make available on 2.5, but rather plan to use 3.x specialities (like e.g. Java 11 features, see https://github.com/openhab/openhab-core/issues/1287), you are free to create a PR against the current master.

We plan to enhance our 3.0.0 build to automatically perform a namespace change of add-ons from the 2.5.x branch and build a 3.0.0 version from them, which would then be included in the 3.0.0 snapshot distros - so working on the 2.5.x branch should be just fine for most right now.

The current idea is to keep it this way for the next 6 months, expecting that we have decent 3.0.0 snapshot and milestone builds by then. We would then retire the 2.5.x branch, commit the code of all add-ons on master and then continue working on master, just as we did in the past.

[lolodomo]

Does it mean we should absolutely avoid updating our local openhab-core master branch if we want to continue updating and compiling bindings for 2.5 runtime ?

[kaikreuzer]

You can update any branch you like at any time. There won't be any need to have any core bundle in your workspace, though as 2.5 add-ons will compile against 2.5 core artifacts.

[Hilbrand]

@lolodomo yes do not update you local core if you want to keep a local core for 2.5. openHAB-core master is on the new namespace. But as Kai mentions you would only need a local branch of core if you made modifications to it, otherwise you should rebase on the 2.5.x branch of openHAB-addons that will compile against the release version of 2.5.

[Hilbrand]

I think we should describe how to rebase an existing branch onto the 2.5.x branch, because it doesn't look trivial and I doubt most people will know how to handle this with git.

[wborn]

The rebase easiness may depend on if PRs have been created before/after the 2.5.0 release. For https://github.com/openhab/openhab-addons/pull/6699 (created after the 2.5.0 release) there were many conflicts after rebasing it on 2.5.x. So I opted for creating a new branch from 2.5.x and cherry picking the commits of that PR onto it. Those conflicts probably won't be there for (most) PRs created before the 2.5.0 release.

[skvalex]

Here are my steps to rebase my PRs against 2.5.x which were created before 2.5.x and were rebased against master several days ago:

1. Changed a base branch from master to 2.5.x on github pull request page
2. git fetch origin 2.5.x
3. git checkout my-branch
4. git rebase origin/2.5.x
5. git rebase --skip # several times
6. git rebase -i HEAD~n # droped commits that don't belong to me from my-branch
7. git push origin my-branch -f

[MrRonfo]

Hi there,
Any hint on how to better work on new binding against 2.5.x with a fresh Eclipse IDE setup ?

Due to the recent change, Eclipse is now automatically installing everything from master pointing at snapshot 3.0.0 - which, as mentioned, leads to have an empty "sample" add-ons folder :/

Thanks

[bjoernbrings]

I've seen some work in Jenkins for 2.5.x 👍.
Will there be any 2.5.x nightlies and corresponding docker files?

[kaikreuzer]

Any hint on how to better work on new binding against 2.5.x with a fresh Eclipse IDE setup ?

After the checkout, simple switch the repos to the 2.5.x branch. Once https://github.com/openhab/openhab-distro/pull/1036 is merged, you should be able to work with the IDE as before.

Will there be any 2.5.x nightlies and corresponding docker files?

We already build nightlies of all add-ons at https://ci.openhab.org/view/Integration%20Builds%20(2.5.x)/.
Will soon do an announcement on how to use them on a 2.5.0 installation. Not sure on what is needed for Docker, though...

[SRGDamia1]

I'm getting a PR ready for a new binding and I can't actually build against 2.5.1 right now. I'm getting this error:

Error resolving artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:2.5.1-SNAPSHOT: [Could not find artifact
org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:2.5.1-SNAPSHOT in openhab-snapshot (https://openhab.jfrog.io/openhab/libs-snapshot/)]

The 2.5.1 karaf snapshot seems to be missing. If I change 2.5.0, I can build fine. If I move up to 3.0.0 and change all of the includes, it also builds fine. Should I put the PR in against 2.5.x (2.5.1) anyway?

[wborn]

The 2.5.x branch is using openhab-core 2.5.0 and not 2.5.1-SNAPSHOT. See https://github.com/openhab/openhab-addons/commit/5fbb18018392cda1dfbe9aae2c26a1e03dc4c7e6. There's a ohc.version property now to manage the openhab-core version.

[SRGDamia1]

I created the empty skeleton just a few days ago and it set everything up as 3.0.0 but I did all the work before you changed the name space. I didn't know there were major changes coming (I wasn't paying attention) until suddenly last night I made a tiny change in the code and went to do a clean rebuild and it exploded with errors because of the namespace changes. It took me a while to figure out how to make it work again.

In case anyone else was stuck on how to fix the include paths:
org.eclipse.smarthome.xxx changes to org.openhab.xxx
and
org.eclipse.smarthome.config.core.xxx changes to org.openhab.core.config.core.xxx
Note the extra "core" in the config path.

[SRGDamia1]

@wborn - thank you, I missed changing that in my feature.xml

[Skinah]

I would like to get the IpCamera binding accepted into 2.5.x branch before the move to 3 but not sure if I can do that in the 8 days left. How busy/long is the queue to get bindings accepted?

[Hilbrand]

@Skinah there will be more 2.5.x releases after 2.5.1, so there will be more opportunities to get it included before 3.0

[kaikreuzer]

there will be more 2.5.x releases after 2.5.1

Slight correction: There won't be any further distros, but there will be further add-on packages. Merged add-ons won't show up in the distro automatically, but it will be possibly to easily install them on a 2.5.1 distro at any time. So to all binding contributors: Whenever it is ready, it is ready and it will soon enough find its way to the users :-) .

[bjoernbrings]

It seems like Jenkins is currently going crazy with the PR builds since the change. Has anything been changed here?

[wborn]

Do you have an example of Jenkins going crazy and which of the many changes do you mean @bjoernbrings?

[Confectrician]

I have recognised long build queues and it seems that builds are reserving a build processor for a long time, even if the build has been aborted from a new commit.

This is my subjective impression from the last days/weeks.

[wborn]

builds are reserving a build processor

It could be the Jenkins bug that has been plaguing us for months now. Sometimes a build process isn't properly terminated and keeps consuming an executor. When this happens several times it will exhaust all available executors causing a big build queue until Jenkins or the agent is manually restarted.

[kaikreuzer]

I couldn't find any obvious cause, but eventually all those jobs end and the executors are freed up again. If you look in the morning, Jenkins is usually idle and all jobs have finished successfully.