Bugzilla – Full Text Bug Listing
| Summary: | org.eclipse.simrel.tests don't run after junit changes made | ||
|---|---|---|---|
| Product: | Community | Reporter: | David Williams <david_williams> |
| Component: | Cross-Project | Assignee: | David Williams <david_williams> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | dennis.huebner |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
David Williams
Dennis, I'm not sure what the issue is, exactly, but ... seems your recent commits for buckminter builds and running as JUnits would be a likely culprit. If nothing else, I deploy these tests with Kepler SR2, platform binary only. ... in other words, no org.junit 4.5.0 as you added. My plan is to revert all the changes you made, and move forward from there, with what I need to do. I asked you to open a bug, before, so we could discuss changes ... if I missed that, my apologies ... if you just did not do it ... well, here it is. We can use this bug to discuss what you want to do and/or how to tell if they are compatible changes. (Oh, and meant to say, I liked some of the changes you made ... I hope they are would be documented somewhere, such as perhaps a new section of https://wiki.eclipse.org/SimRel/Simultaneous_Release_Reports_Running_Locally ) but, my point is, I hope you don't get discouraged. I very much appreciate the efforts to improve them, and get them into wider use ... but ... its simply I don't appreciate breaking the Sim. Repo tests. Thanks, These were the changes I reverted. (And, once I did, the tests for Sim. Release ran again, when re-deployed). 6bb01da67bb8c306d15be56da68b5d6e6d025c70 Revert "[bucky] Added buckminster config files" c55db157597f8bcac6afb1f3cf1441eafb426fc7 Revert "Merge branch 'master' of ssh://dhubner@git.eclipse.org/gitroot/simrel/org.eclipse.simrel.tests.git" 744e7ca5003501f6f07c1e5e09fb0e7eabb1e366 Revert "[bucky] fixed local locator pattern" 1f687cce659a86ea087b7748d985668be66fb837 Revert "[junit] added junit launch configs" 4355f2425016c1f1709ddcf4a674f230ee48cef8 Revert "[bucky] add more test-time dependencies using cspex" 295df0a1f21948bb3da29d34fbb213182a668bcd Revert "[bucky] added missing dependency" 9af32b65993455224a330379909c67231e4d32ad Revert "[junit] do not fail the test in BeforeClass " 0d8a3221501c0fea600e0d644de935ec51a7bde4 Revert "[junit] bypass env_var args" 039bad73c46b54ddd8fcd8083902cdc020b68b5e Revert "[misc] Fixed build.props. Dump env_vars only if param is passed" All of them could likely be "unreverted", if "innocent", except for the "branch" ... I've heard you can't revert a revert of a branch ... or that it's hard? ... (which is one reason it's discouraged?) ... so hope you know what that's about. I'm glad to talk more what changes you need ... if it's just a matter of me installing the sdk instead of binary platform, I guess that's not a bit deal ... but ... want it to be discussed, etc., alternatives considered, etc. FYI, I don't "build" this in any fancy way ... I just build the jar in work bench, and then "deploy" by copying into "dropins". Undoubtedly primitive compared to what ever you are doing. Once again, thanks for your help, I'm looking forward to learning more about what you are doing and learning how I can help (and if it seems like a simple "fix" should have been obvious, I'll remind you to consider who you're talking to :) One last comment. At the very beginning, I had trouble running the tests "directly from the workbecnh" ... as though JUnit was somehow interfering with standard running. trying it just now, adding junit to manifest, didn't cause any problems, but of course no code was using it. I didn't look too deeply at it, but that is a good test that "all is well" for both use-cases. I believe it was repoEclipseReportsTests I was trying, with value such as follow ... tnat 's literally making a copy of repo on my local machine. -Dosgi.requiredJavaVersion=1.6 -XX:MaxPermSize=256m -Xms40m -Xmx512m -DreportOutputDir=/home/shared/simrel/luna -DreportRepoDir=/home/shared/simrel/luna/aggregation/final It would be good to see the log of the failed build: /opt/public/simrel/luna/org.eclipse.simrel.tests/eclipseWorkspace/.metadata/.log AFAIK junit and hamcrest are not the parts of the platform zip. You are using FULL_FILENAME_430=/home/data/httpd/archive.eclipse.org/eclipse/downloads/drops4/R-4.3.1-201309111000/eclipse-platform-4.3.1-linux-gtk-x86_64.tar.gz right? So I suppose the missing junit dependency caused the problem. Setting it to optional will solve the issue. To make both cases working (my job is failing now) I've tried to push a new remote branch "junit" but have not enough permissions to do so. It would be nice to have a separate branch, so you can review my changes or test them before merging into master. (In reply to Dennis Huebner from comment #5) > To make both cases working (my job is failing now) I've tried to push a new > remote branch "junit" but have not enough permissions to do so. Did you try a "topic branch" of the form <committer-id>/junit-addition? I'd be surprised if that <committer-id> version doesn't work (most repos are set up this way to allow anyone to do "sandbox" work in the repo, but by having the committer-id in there, makes it clear they are not necessarily "long lived", etc. (In reply to David Williams from comment #6) > (In reply to Dennis Huebner from comment #5) > > > To make both cases working (my job is failing now) I've tried to push a new > > remote branch "junit" but have not enough permissions to do so. > > Did you try a "topic branch" of the form <committer-id>/junit-addition? > It works. Thanks for the hint! I've created dhubner/junit branch. (In reply to Dennis Huebner from comment #7) > (In reply to David Williams from comment #6) > > (In reply to Dennis Huebner from comment #5) > > > > > To make both cases working (my job is failing now) I've tried to push a new > > > remote branch "junit" but have not enough permissions to do so. > > > > Did you try a "topic branch" of the form <committer-id>/junit-addition? > > > > It works. Thanks for the hint! > I've created dhubner/junit branch. I've cherry picked your changes from master. The state of dhubner/junit now contains my and your changes. Could you try it out? Thanks Dennis ... I will give a try, first in workbench, then on my local test machine, and then deploy. I assume you are saying I should just use the "SDK", right? Since I just "build the jar" (using that existing simreltests.jardesc) from the workbench and deploy to "dropins"? (In reply to David Williams from comment #9) > Thanks Dennis ... I will give a try, first in workbench, then on my local > test machine, and then deploy. I assume you are saying I should just use the > "SDK", right? Since I just "build the jar" (using that existing > simreltests.jardesc) from the workbench and deploy to "dropins"? You can keep using platform zip (it's just 60 mb big). junit is not needed in your case, as you are not launching junit tests, so it must work. For me all remain also the same, because buckminster pulls all the needed bundles automatically and creates the right target platform. (In reply to Dennis Huebner from comment #10) > (In reply to David Williams from comment #9) > > Thanks Dennis ... I will give a try, first in workbench, then on my local > > test machine, and then deploy. I assume you are saying I should just use the > > "SDK", right? Since I just "build the jar" (using that existing > > simreltests.jardesc) from the workbench and deploy to "dropins"? > > You can keep using platform zip (it's just 60 mb big). junit is not needed > in your case, as you are not launching junit tests, so it must work. > For me all remain also the same, because buckminster pulls all the needed > bundles automatically and creates the right target platform. Oh yes, you already said optional. Ok, well work bench and local test machine tests (my tests) all work as before. Hope yours do too :) You are welcome to merge dhubner/junit back into master, and I'll give it try on "real" machine (eclipse.org) after lunch today. (In reply to David Williams from comment #11) > You are welcome to merge dhubner/junit back into master, and I'll give it > try on "real" machine (eclipse.org) after lunch today. For the record, I tried to do the merge, and it just never could get it to go as smoothly as I thought it should. I think there's something I don't understand about merging, or perhaps I "messed up" dhubner/junit by making a few commits there (to help test it) then reverting them.So I can do the "sloppy merge" if you'd like ... but hoping you might know more about best way to merge? Let me know if you have a preference. (In reply to David Williams from comment #12) > (In reply to David Williams from comment #11) > > > You are welcome to merge dhubner/junit back into master, and I'll give it > > try on "real" machine (eclipse.org) after lunch today. > > For the record, I tried to do the merge, and it just never could get it to > go as smoothly as I thought it should. I think there's something I don't > understand about merging, or perhaps I "messed up" dhubner/junit by making a > few commits there (to help test it) then reverting them.So I can do the > "sloppy merge" if you'd like ... but hoping you might know more about best > way to merge? > > Let me know if you have a preference. Right now I can't even pull from git.eclipse.org using ssh: MacHuebner:simrel-build-tests dhuebner$ git pull ssh: connect to host git.eclipse.org port 22: Operation timed out fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Our IP was locked by ssh auth bot, although I've got an "unlock success" mail. Assuming fixed, since works now. |