Regarding the authentication... As I recall during build for somethings, the builds still had to be certified in some way before fully usable. Is this any different then authentication with Github? See https://docs.github.com/en/packages/learn-github-packages/about-github-packages#authenticating-to-github-packages
Not an expert here but it sounds like the action can be setup to give certain roles (i.e. read only vs write). So in this case would the main folks in control of the apache/netbeans setup the roles and access so that those building would have "write" / "publish" access while others would have "read" access to the interim build jars. I suppose in theory a follow on would be to publish them to maven repo afterwards as another action but this is all hypothetical to me at the moment. Eric Bresie [email protected] On Mon, Feb 1, 2021 at 4:27 AM Lars Bruun-Hansen <[email protected]> wrote: > On Mon, Feb 1, 2021 at 10:48 AM Neil C Smith <[email protected]> > wrote: > > > > On Sun, 31 Jan 2021 at 19:18, Lars Bruun-Hansen <[email protected]> > wrote: > > > I had the exact same idea for example in relation to Apache NetBeans > > > native artifacts (launcher, nbi libs, nbi launcher, profiler libs) > > > because the https://netbeans.osuosl.org/binaries/ is really meant to > > > be a site for truly external binaries, i.e. those that are *outside* > > > of the Apache NetBeans project. So using something more internal to > > > the build pipeline would be preferable. > > > > Well, if they're our "internal" artefacts then an internal release > > process would certainly be preferable. If we can consider certain > > chicken-and-egg issues here (ie. binaries required at IDE build time), > > then a separate source and binary release process for these and > > distribution via standard ASF channels might be the right way to > > approach this? > > > > Yep. I was considering that the right place for such internal > artifacts might be ASF's Maven Repo. The problem I see with that one > is that it is meant for _released_ artifacts meaning official ASF > releases. They need to go through the voting process. This is not the > case for these particular artifacts, they are in effect interim, and I > don't think the community need more artifacts that we need to vote > on?. > > For these particular build results we "just" need a place to store > them which offers: > (1) acceptable up-time. > (2) long term durability > (3) immutability (a standard trait for most Maven repos .. once an > artifact is published it can never be overwritten) > (4) publication access tightly linked to project commit permission. > (we don't need more stuff to administer) > (5) consumable via http(s) (so can be used via the Ant > DownloadBinaries task) without requiring authentication (so doesn't > require user to jump through hoops to build NetBeans) > (6) not seen as a channel for official ASF releases. > > GitHub Packages would have been perfect IMO ... if it wasn't for that > small caveat about authentication, i.e. it GitHub Packages fail on > requirement #5, but pass on all others. > > We can publish them into the ASF Maven Repo as SNAPSHOTS but they are > really not and such solution would fail on #2 and #3 depending on how > the ASF operates its Nexus Repo. > > Lars > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
