Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cbi-dev] Procedure to deploy to download.eclipse.org
As stated in https://bugs.eclipse.org/bugs/show_bug.cgi?id=482881, you may need to archive the desired path in order to have it under the builds/2015-11-23_11-00-37 path.

Cheers,
Mikael

Le 24 nov. 2015 à 09:53, LE FEVRE FRANCOIS <francois.le-fevre@xxxxxx> a écrit :

Hallo,
That is more precise, thanks
 
However I am still getting an error.
And perhaps it is due to access right?
 
The job 
 
The copy problem:
 
cp: cannot stat `/jobs/genie.papyrus/papyrus-sysml-nightly-build/builds/2015-11-23_11-00-37/org.eclipse.papyrus-sysml/releng/org.eclipse.papyrus.sysml14.p2/target/repository/*': No such file or directory
Copied /jobs/genie.papyrus/papyrus-sysml-nightly-build/builds/2015-11-23_11-00-37/org.eclipse.papyrus-sysml/releng/org.eclipse.papyrus.sysml14.p2/target/repository to local directory update-site.
find: `update-site/features/': No such file or directory
 
 
It seems that the $localUpdateSite is not accessible?
It came from the concatenation of
 
jobDir=/jobs/genie.papyrus/papyrus-sysml-nightly-build/builds/2015-11-23_11-00-37
targetUpdateSite=org.eclipse.papyrus-sysml/releng/org.eclipse.papyrus.sysml14.p2/target/repository
 
targetUpdateSite is a fixed parameter
jobDir comes from the reverse lookup of the buildId.
 
 
I didn’t modify your core script, I have just added elements to reflect my project settings just as the targetUpdateSite
 
Sorry to disturb you with that.
 
Francois
 
 
 
 
 
 
De : cbi-dev-bounces@xxxxxxxxxxx [mailto:cbi-dev-bounces@xxxxxxxxxxx] De la part de Alexander Nyßen
Envoyé : lundi 23 novembre 2015 17:13
À : Common-build Developers discussion <cbi-dev@xxxxxxxxxxx>
Objet : Re: [cbi-dev] Procedure to deploy to download.eclipse.org
 
Hallo Francois,
 
our builds are configured to archive the created update-site as a build artifact. As we do not promote nightly updates to download.eclipse.org, we copy the created update-site to a root folder named „update-site“ before archiving it, using a shell script that is executed after the real build:
 
if [ -d "update-site" ]; then
  rm -fr update-site
fi
mkdir update-site
cp -R org.eclipse.gef.repository/target/repository/* update-site/
 
This enables us to use concise URLs for our nightly update-sites, e.g. https://hudson.eclipse.org/gef/job/gef4-master/lastSuccessfulBuild/artifact/update-site.
The (unmodified) section of our publish script corresponds to this:
 
jobDir=$(readlink -f ~/.hudson/jobs/$jobName/builds/$buildId)
if [ ! -d $jobDir ];
then
            echo "The specified buildId does not refer to an existing build: $buildId"
            exit 1
fi
localUpdateSite=$jobDir/archive/update-site
echo "Publishing from local update site: $localUpdateSite“
 
Hope that explains it.
 
Cheers
Alexander
 
Am 23.11.2015 um 16:56 schrieb LE FEVRE FRANCOIS <francois.le-fevre@xxxxxx>:
 
Alexender,
In fact my problem is related with the following script part of publish.sh
 
jobDir=$(readlink -f ~/.hudson/jobs/${jobName}/builds/${buildId})
localUpdateSite=${jobDir}/${targetUpdateSite}
 
localUpdateSite is ever leer?
 
Do you have any idea?
 
Thanks
 
 
 
De : cbi-dev-bounces@xxxxxxxxxxx [mailto:cbi-dev-bounces@xxxxxxxxxxx] De la part de Alexander Nyßen
Envoyé : lundi 2 novembre 2015 18:54
À : Common-build Developers discussion <cbi-dev@xxxxxxxxxxx>
Objet : Re: [cbi-dev] Procedure to deploy to download.eclipse.org
 
Hallo Francois,
 
you will need to have the HIPP user be added to your project group (the admins can do that for you) and might have to adjust the group permissions in your download area (so the group has write access) as well. 
 
Cheers
Alexander
 
Am 02.11.2015 um 18:05 schrieb LE FEVRE FRANCOIS <francois.le-fevre@xxxxxx>:
 
Alexander ,
So I have downloaded your publish.sh script.
I have made two small modifications to be compliant with our own product (mainly the url ) .
The script of Alexander is really good and do the job perfectly. (at least locally for test)

Script here : https://git.eclipse.org/r/#/c/59473/ ; pending review

I have still a question regardling Camille post.
If I create a job that will process the script as second task, how can I setup the permissions to be sure the script could write to the downloads area?

Do I need to ask for the creation of a specific user with those rights for a specific directory?

Francois

-----Message d'origine-----
De : cbi-dev-bounces@xxxxxxxxxxx [mailto:cbi-dev-bounces@xxxxxxxxxxx] De la part de Mikael Barbero
Envoyé : mardi 27 octobre 2015 15:15
À : Common-build Developers discussion <cbi-dev@xxxxxxxxxxx>
Objet : Re: [cbi-dev] Procedure to deploy to download.eclipse.org




Le 27 oct. 2015 à 14:41, Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx> a écrit :

Mikael Barbero wrote:


I think much of this can be tackled by Maven plugins during the 
build already. I can very well imagine 
tycho-p2-repository:archive-repository
learning to compress the update site with zx as well.

Of course. We have to weight what has to be done on the client side and on the server side. However, for things that we want to enforce, I think this is much easier to do it on the server side.



Same thing goes for mirror and stats URIs.

Yes, on the server side we can implement some checks and reject repos 
that don't meet the criteria instead of doing the actual work. 
However, I think that everybody will more than happy if the server 
does most of the hurdle and they don't have to change their build to 
do it. Moreover, improvements on the server side are much easier to 
deploy than to convince everybody to use a new version of a Maven 
plugin ;)

Implementing the checks on the server (web-service) side and rejecting 
if the quality criteria (no mirror URIs, no index.html, whatever) are 
not met sounds reasonable.

I would just prefer if much of the actual metadata would be filled in 
on the client/build side, not by the server/publisher. In particular, 
this makes it much easier to test things locally; just look at the 
artifacts.xml and check whether the stats URI is set, for example.

Also, you would not need to pass so many arguments to the publisher 
server (like stats URI, mirror URI, project description). All that 
IMHO should be required is the desired location on download.eclipse.org.

I envision this to be a bit like Maven Central. You upload your 
JAR+POM, it gets checked, and then published at a certain location of 
all quality criteria are met.

In fact, I think Tycho by default already produces the perfect 
artifact to upload to a publishing web service: the zipped update site.

What do you think?

Sounds reasonable to me. However, for some items like the index.html, I still see a real added value for the community if the service generate a default one when missing.

Cheers,
Mikael

_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cbi-dev
 

--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nyssen@xxxxxxxxx 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino


 
_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cbi-dev
 

--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nyssen@xxxxxxxxx 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino

 
_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cbi-dev

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Back to the top