On 03/22/2016 06:20 PM, David M Williams wrote:
I'll give advise on
part of what you say.
If you use use Hudson then for
"SNAPSHOTS"
it might suffice just to point people to
"..../last/successful/repository
(or, whatever it is called). That assume not too many people
would be "getting"
those. (Since Hudson is not optimized for lots of downloading).
We use Jenkins, but we upload our artifacts to a
Nexus repo.
Then, if you are literally "at
Eclipse" you might want an /integration and/or /milestone
directory
that matched the I-build or milestone of "Eclipse codebase" you
were building against.
I don't understand what you mean by "at Eclipse".
/release I would call "/releases"
assuming you will have more than one. Which brings me to the
main part
of my advice. You say "Each of these
would
just get the latest". But
you want to be careful not to remove, and replace one repository
with another.
For several reasons. 1) There is a generally an expectation (at
least at
Eclipse) that "releases" are retained for a long long time (if
not "forever") just because someone may be building on *your*
release, and have some update or maintenance to make in years to
come.
2) Especially for "releases" but even "integration"
or "milestones" there is an assumptions that p2 repositories
are immutable. 3) An easy strategy to accomplish a little of
both
(short URL and immutable repositories) is to use composites, so
that /releases
would have under it "release1" but also, eventually "release2",
etc. You can have "composite" metadata just under "/releases"
to "combine" the releases if you'd like. One advantage of that
approach, even for "snapshots", or milestones or what ever is
that if a user (or, "builder") is using one repository, they
will continue working as you put a new one in place and then add
to composite.
Otherwise, there is a risk what ever they are downloading will
suddenly
disappear.
In that case, I would think it's reasonable for
releases to go into a composite update site. I've briefly heard
about this concept, but I need to know more about it. Is this
something I would augment my Tycho build to produce, or do I just
set up the composite structure on a server and then deploy new
update site releases to it?
I don't think I need this structure for artifacts that come
between releases, being snapshots. I don't think it's likely
we'll need "integration" or "milestone" releases in composite
update sites.
HTH
From:
"David M. Karr"
<davidmichaelkarr@xxxxxxxxx>
To:
Tycho user list
<tycho-user@xxxxxxxxxxx>,
Date:
03/22/2016 07:39 PM
Subject:
[tycho-user]
Strategies for defining update site url
Sent by:
tycho-user-bounces@xxxxxxxxxxx
I'm working on an Eclipse plugin codebase, and
I've
gotten to the point
where the build server is producing the update site zip file.
I now
need to think about reasonable strategies for defining an
update site
URL. The simplest strategy would be a single URL that I
publish
everything to, snapshots and releases. That's probably not a
good idea.
Is it as simple as just defining a "/release" url and a
"/snapshot"
url
and leave it at that? Each of these would just get the latest
release
or snapshot respectively.
Obviously, I have to work with my infrastructure team to make
the URLs
available, I just want to start with something that will be
maintainable.
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
|
