The new scripts look good to me. With the *-sub-repo scripts we can get rid of our old codegen scripts.
Mind you, there are a whole bunch of scripts under releng/toolkit that I think were adapted from Papyrus and which I suspect are a lot more sophisticated than our simple postbuild.sh/archive.sh.
I don't know what those releng/toolkit scripts do. Probably Remi or Camille know about this. Or whether we need what those scripts do.
But as far as I'm concerned your scripts are good for us.
Can you have a look in my last gerrit [1] and check the shell script
? It should be called from the jobs.
As you can see, I dupplicated more or less the codegen script and
the p2 directory.
This is to have an homogeneous project and have a symetry between
codegen, core and tooling p2's. Which I called sub-repo's .
Regards
Céline
Le 03/06/2016 à 15:41, Ernesto Posse a
écrit :
Actually you don't need special access permissions.
See my answer in the bug.
The Prinscreen is for the CodegenRTS-gitpoll job AND
Master-All Job
Then both Codegen and Tooling, core, profile modifications
will trigger the Product job.
In the furtur, (short term), I would like to copy the
product Artifacts into eclipse download p2 as for Codegen.
But i'm waiting for the rights and the process ;) [1]
Wouldn’t it make
more sense for this
build to be a
downstream build of
all of the component
builds, so that it is
triggered whenever one
of them produces a new
build? Because its
purpose is to
re-package the
binaries produced by
those builds.
Otherwise, if
it is triggered by
source changes, it
will be triggered at
the same time as the
component builds and
so will always be
lagging behind them
in its content.
I
just checked
the
configuration
for this job
and it is set
to poll every
15 minutes, so
I expect this
should work
for you. I've
added you to
the list of
users that can
configure this
job. I think
you should be
able to see it
now. (https://hudson.eclipse.org/papyrus-rt/job/Papyrus-RT-Product/)
By
the way, we
are also
planning a
more stable
weekly
integration
build repo
which could be
used to make
sure that the
developer and
tester setup
models don't
throw errors
when trying to
access the
repo.
What about the
update
frequency for
this update
site then? Has
it the same
poll frequency
checking for
merges to the
master branch
as the
previous one,
i.e. 20
minutes? Or is
this new
update site
updated less
frequently,
time triggered
as true
24-hour
nightly build?
We (at least
I) really need
an update site
that is
updated often
to able to
provide quick
feedback if
needed. I
don't want to
wait until
next day to be
able to get
the latest
build of
Papyrus-RT.
I can't see the
build
configuration
for this new
build (as I
can for the
other one
since I got
permissions to
be able to
retrigger that
job in case it
had failed,
which I won't
be able to do
for this new
job then).
@Peter,
I've pushed 74446 to
fix the setup
files. There
are still some
wrinkles that
need to be
ironed out
before merging
this.
Celine
has been
working on a
restructuring
of the build
jobs and we've
been having
some
discussions
about the p2
repos. I hope
this can be
settled soon.
is
the one that
we always have
used for the
core, profile
and tooling
builds, and
has been built
within 20
minutes after
something had
been merged to
master, to be
able to
provide quick
feedback. I am
not sure how
the
Papyrus-RT-Product
builds has
been
configured, if
it checks for
changes in Git
equally often,
or if it has a
strict time
based trigger.
Shouldn't
this change
have been
identified and
announced a
bit earlier?
All setup
files that we
have reference
the (now
empty) p2 repo
earlier
produced by
the
Papurys-RT-Master-All build. Those setup files (that we have in the
website repo),
including any
users that
have made
their own
setup files,
will now have
to be updated.
Those setup
files are now
broken for
installations
based on the
latest builds.
For your
information,
the Hudson
Jobs
Gerrit-master
and Master-All
won't build
the releng
part anymore.
The releng
part contains:
p2, rcp,
product and
the main
feature.
The job
Papyrus-RT-Product
is now in
charge of
building those
items.
NOTE: If you
have
dependencies
with
Master-All
artifacts, You
may need to
point to
Papyrus-RT-Product
artifacts
instead.