Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling of Pull Requests #6702

Closed
kaikreuzer opened this issue Dec 29, 2019 · 23 comments
Closed

Handling of Pull Requests #6702

kaikreuzer opened this issue Dec 29, 2019 · 23 comments

Comments

@kaikreuzer
Copy link
Member

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 openhab/openhab-core#1294.
In consequence, none existing add-ons compile against this code anymore and thus have been removed with #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 openhab/openhab-core#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
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Member

@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
Copy link
Member

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
Copy link
Member

wborn commented Dec 29, 2019

The rebase easiness may depend on if PRs have been created before/after the 2.5.0 release. For #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
Copy link

skvalex commented Dec 30, 2019

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
Copy link

MrRonfo commented Dec 30, 2019

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
Copy link
Contributor

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

@kaikreuzer
Copy link
Member Author

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 openhab/openhab-distro#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
Copy link

SRGDamia1 commented Dec 30, 2019

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
Copy link
Member

wborn commented Dec 30, 2019

The 2.5.x branch is using openhab-core 2.5.0 and not 2.5.1-SNAPSHOT. See 5fbb180. There's a ohc.version property now to manage the openhab-core version.

@SRGDamia1
Copy link

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
Copy link

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

@Skinah
Copy link
Contributor

Skinah commented Jan 4, 2020

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
Copy link
Member

Hilbrand commented Jan 4, 2020

@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
Copy link
Member Author

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
Copy link
Contributor

bjoernbrings commented Jan 9, 2020

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

@wborn
Copy link
Member

wborn commented Jan 10, 2020

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

@Confectrician
Copy link
Contributor

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
Copy link
Member

wborn commented Jan 11, 2020

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
Copy link
Member Author

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.

@clinique
Copy link
Contributor

@kaikreuzer : maybe we could close this issue ?

@kaikreuzer
Copy link
Member Author

Yeah, indeed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests