search

eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[releng] Automate the creation of p2.mirrorsURL and p2.statsURI properties in the generated properties #724

Open eclipse-ocl-bot opened 2 months ago

eclipse-ocl-bot commented 2 months ago

| --- | --- | | Bugzilla Link | 349300 | | Status | NEW | | Importance | P3 normal | | Reported | Jun 14, 2011 06:31 EDT | | Modified | May 27, 2014 12:51 EDT | | Version | 3.1.0 | | Depends on | 373667 | | Reporter | Adolfo Sanchez-Barbudo Herrera |

Description

During the quite week, I've been working on the (manual) introduction of some interesting p2 properties in our Indigo release repository[1]

More information about these properties may be found here [2] [3].

It could be interesting to automate the introduction of such p2 properties during the build process. It needs investigation.

[1] http://download.eclipse.org/modeling/mdt/ocl/updates/releases/3.1.0 \ [2] http://wiki.eclipse.org/Equinox/p2/p2.mirrorsURL\ [3] http://wiki.eclipse.org/Equinox_p2_download_stats

eclipse-ocl-bot commented 2 months ago

By Laurent Goubet on Jun 14, 2011 06:55

Adolfo,

I don't know how you add the p2.statsURI to the update site, but we do this (semi-)automatically for Acceleo and EMF Compare through the evaluation of an xslt stylesheet when we promote new versions. We promote manually by logging in on dev.eclipse.org and using a command such as "ant -f promoter.ant"... and this ant file calls the xslt engine on our update site before publishing it.

I don't know if such a method can be applied for OCL, but for the record, you can find how we do this in :pserver:dev.eclipse.org:/cvsroot/modeling/org.eclipse.m2t/org.eclipse.acceleo/releng/org.eclipse.acceleo.releng.

The files of interest in there are addDownloadStats.xsl and promoter.ant.

If you wish to use this method and need more information, you have my Skype id :).

eclipse-ocl-bot commented 2 months ago

By Adolfo Sanchez-Barbudo Herrera on Jul 27, 2011 13:41

My last tests looks like to produce the expected artifacts.xml in the p2.repository version (including the zipped one which will be available in downloads).

However, there is a weird behavior:

Looking at our last master's successful build, the tuning scripts were properly executed, because in our ocl-build feature we have a modified artifacts.xml which properly contains the p2.statsURI and p2.mirrorsURL properties [1]. However the produced p2 repository doesn't contain them [2]

On the other hand, where are the archived artifacts from said I-build [3]? ... It's not the first time it happens >.<

P.S: Laurent, thanks for the information. I finally took as reference the Xtext stuff, since it also had a similar stuff to do that and I already had it in my workspace ;). If it helps to you we are now also including the mirrorsURL in the generated p2 repository

P.S2: UPDATED: The last build[4] (run automatically) contains the properties...

[1] https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.2-master/ws/org.eclipse.ocl.git/releng/org.eclipse.ocl.build-feature/artifacts.xml/*view*/\ [2] https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.2-master/401/artifact/MDT-OCL.p2.repository/

[3] https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.2-master/397/

[4] https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.2-master/402/artifact/MDT-OCL.p2.repository/

Best Regards,\ Adolfo.

eclipse-ocl-bot commented 2 months ago

By Adolfo Sanchez-Barbudo Herrera on Jul 28, 2011 09:24

Update with our last automatically run builds:

Maintenance (M-builds) [1]: Does include the modified artifact.xml\ Master (N-build) [2]: Doest NOT include the modified artifact.xml

Random Powah !! ... :(

Laurent, have you had any similar issue to this one ?. Does your generated p2 repository artifact.xml ALWAYS include the p2.statsURI property ?

[1] https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-3.1-maintenance/621/artifact/MDT-OCL.p2.repository/\ [2] https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.2-master/403/artifact/MDT-OCL.p2.repository/

eclipse-ocl-bot commented 2 months ago

By Laurent Goubet on Jul 28, 2011 09:33

(In reply to comment #3)

Update with our last automatically run builds:

Maintenance (M-builds) [1]: Does include the modified artifact.xml Master (N-build) [2]: Doest NOT include the modified artifact.xml

Random Powah !! ... :(

Laurent, have you had any similar issue to this one ?. Does your generated p2 repository artifact.xml ALWAYS include the p2.statsURI property ?

[1] https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-3.1-maintenance/621/artifact/MDT-OCL.p2.repository/ [2] https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.2-master/403/artifact/MDT-OCL.p2.repository/

We add these properties only when we promote our builds... So I can't really help here. I am confident that our promoted builds have them since we promote through an ANT file and it is that very ant file which is in charge of adding that stuff.

For something automated with every build ... I don't know :s. Maybe your script does add the two necessary properties, but does/can not re-zip the artifacts file?

eclipse-ocl-bot commented 2 months ago

By Adolfo Sanchez-Barbudo Herrera on Dec 22, 2011 13:52

Remembering to change the scripts to discern stats for core and tools downloads

eclipse-ocl-bot commented 2 months ago

By Adolfo Sanchez-Barbudo Herrera on Mar 08, 2012 11:48

(In reply to comment #5)

Remembering to change the scripts to discern stats for core and tools downloads

Before doing that, I should do the merge between core and tools build, so that I only have one place on which work

eclipse-ocl-bot commented 2 months ago

By Adolfo Sanchez-Barbudo Herrera on Jun 10, 2013 13:04

Today, I've been trying to track what's wrong with this issue.

My experience on randomness implies some hudson node related issues:

I've tried the following nodes, with no stats/mirrorsURL after all:

If I'm not able to produce the desired P2 repository, I'll promote it anyway. If no luck tomorrow with Tools one, I'll add them manually during the quiet week.

[1] https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-kepler-master/804/\ [2] https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-kepler-master/806/

eclipse-ocl-bot commented 2 months ago

By Adolfo Sanchez-Barbudo Herrera on Jun 11, 2013 07:59

The third try worked:

After having lunch, I'll use the Tools RC4 build to verify if the hudson node is related to the randomness of the success of the p2 repostiory tuning activities.

[1] https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-kepler-master/808/

eclipse-ocl-bot commented 2 months ago

By Adolfo Sanchez-Barbudo Herrera on Jun 11, 2013 14:19

Tools report. No stats after kicking out the build in the current configured node:

I'm trying hudson-slave1 to see if now succeeds as it happened yesterday with the Core build.

Curiously, every time I changed the node the next build fails with a "NFS stale" error. The next one works (as my experience Yesterday). Running the job again to see the final result, what respects the P2 repository tuning activities.

eclipse-ocl-bot commented 2 months ago

By Adolfo Sanchez-Barbudo Herrera on Jun 11, 2013 15:09

(In reply to comment #9)

Running the job again to see the final result, what respects the P2 repository tuning activities.

No way :(. The randomness is not related to specific nodes. In hudson-slave1 p2 repo tuning activities worked yesterday with OCL Core build, however it didn't work today with OCL Tools one.

eclipse-ocl-bot commented 2 months ago

By Ed Willink on May 27, 2014 12:51

(In reply to Adolfo Sanchez-Barbudo Herrera from comment #9)

"NFS stale" error

can be caused by Buckminsters allocation of temp directories from a shared pool. Some other job may re-use and evn lock out with wrong ownership.

Now that we have a HIP for OCL+QVTd such conflicts should not arise.

Now that we don't have distinct Core/Tools builds it may be easier.

May be worth another try.