| Summary: | Prepare for Mars + Luna_maintenance split stream development | ||||||
|---|---|---|---|---|---|---|---|
| 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, krum.tsvetkov, mistria, mknauer | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
David Williams
I think we are almost all set. I created a "Luna_maintenance" branch off master, just picking today's date as the starting point, since some contributions have already changed since Luna release (to change URL to final location ... if nothing else), and I was able to "build" each, promote each: Mars into 'staging' and Luna now into 'maintenance', and the results were exactly the same, as would be expected. As of now, I've contributed a "warmup" version of the Eclipse Platform and Equinox for Mars M1 (recent I-build) in master branch, and a "warmup" for Luna SR1 (a recent M-build) to Luna_maintenance. Assuming those both "build", I can compare and make sure "staging" and "maintenance" are getting what they are supposed to be getting. After that, I will re-enable "--production" flag (which is what causes "blame mail" to be sent out ... AND ... I need to reconnect the "promotion" back to epp builds. Markus, for Luna, we had me "signal" the job named https://hudson.eclipse.org/packaging/job/luna.epp-tycho-build/buildWithParameters?token=.... may I assume for mars it would be https://hudson.eclipse.org/packaging/job/mars.epp-tycho-build/buildWithParameters?token= (same token for both?) And, if you haven't yet, if you could simply define an "empty" mars job ... as if it doesn't exist at all, it may cause the Mars aggregation job to "fail" due to "job not found"? (but, not really sure about that). Thanks, For those into nitty-gritty, thought I'd be explicit that (currently) org.eclipse.simrel.tests, and org.eclipse.simrel.tools both come from master and are used in each aggregation ... which is possible since the critical parts are defined as variables and locations via Hudson job configuration. In theory, there could be reason to split stream them some day ... but, I try to avoid that, if at all possble. Created attachment 245781 [details]
Include SWTBot in Mars
@David: can you please review and merge the following contribution for SWTBot?
(In reply to Mickael Istria from comment #3) > Created attachment 245781 [details] > Include SWTBot in Mars > > @David: can you please review and merge the following contribution for > SWTBot? New contributions is not the purpose of this bug, but I did it anyway, for this one case. I assume you've applied for "committer ship", if you are not already? While in b3aggregator editor, I was seeing one error: org.eclipse.swtbot.gef.feature.group was not found. So, I just disabled that one feature, and will leave to you to fix what ever that issue is, but committed rest. I'm going to mark this as fixed ... though still need to work out with Markus what jobs to trigger. But, everything else is done, apparently the "production" flag was already set, so guess I disabled it locally only? ... or there is another place I need to fix before blame mail works again? Bet we'll know soon enough if it works :) I will say, it took longer than expected to finish since in my second test run, when contents should have been different, it turned out they were the same, and the reason (after much debugging) was we previously relied on "checking out the correct branch" when we cloned the repo ... and the branch could never change, after that. And there were some errors in Hudson setup, initially, that caused both streams to check out 'master', initially. So, I expanded the "git processing" a fair amount so it is now possible to get a new branch at any time. Besides yearly mistakes in setup, this will prove handy in those few cases where we may temporarily need to build with a "Luna_maintenance_B" branch, or similar. Now we will require only a change in Hudson parameters. Previously, we'd have to change tool scripts, AND re-clone the repo. But, I think all is working now (except EPP notification). If anyone sees or suspects any errors, let me know. To keep everyone updated... see comments below. (In reply to David Williams from comment #1) > Markus, for Luna, we had me "signal" the job named > > https://hudson.eclipse.org/packaging/job/luna.epp-tycho-build/ > buildWithParameters?token=.... > > may I assume for mars it would be > > https://hudson.eclipse.org/packaging/job/mars.epp-tycho-build/ > buildWithParameters?token= > > (same token for both?) Yes, same token for both, and assumption is correct. I already re-enabled the trigger in both simrel.{luna,mars}.lockForPromotion jobs. > And, if you haven't yet, if you could simply define an "empty" mars job ... Done. * luna.epp-tycho-build at https://hudson.eclipse.org/packaging/job/luna.epp-tycho-build/ uses the Luna (maintenance) repository as input and works on the LUNA EPP branch in our Git repository. Configuration is already updated for Luna SR1. * mars.epp-tycho-build at https://hudson.eclipse.org/packaging/job/mars.epp-tycho-build/ is building from Mars (staging) and uses our Git master branch. Configuration needs to be updated to Mars. |