FYI, I managed to build Royale using Maven using Royale instructions [1] The only missing instruction was about mvn install-file for airglobal-20.0.swc.
I measured what you deploy to the repository: with 206 MB of content for asjs containing a distribution of 2 files of 50 MB each, I can understand that any network issue can cause a failure here and that's unpleasant. I just added a documentation in maven-deploy-plugin on how to deal with network issues [2]: I'm pretty sure the local staging directory strategy could perfectly match your case. Hope this helps, Hervé [1] https://github.com/apache/royale-asjs/wiki/Build-Apache-Royale-with-Maven [2] https://maven.apache.org/plugins-archives/maven-deploy-plugin-LATEST/examples/deploy-network-issues.html Le mercredi 9 janvier 2019, 08:54:10 CET Hervé BOUTEMY a écrit : > did anybody try the intersting proposal from Christofer (doing like PCL4X)? > > looks promising for Royale > > Regards, > > Hervé > > Le mardi 8 janvier 2019, 02:35:07 CET Hervé BOUTEMY a écrit : > > yes, given Royale issue looks like network connectivity reliability (and I > > suppose numerous and large artifacts), deploying to a local file:// based > > repository then having a pure upload step from file:// rlocal repository > > to > > network based staging repository could be a solution that would be less > > intrusive than changing the full process > > > > I don't have immediately a plugin in mind for such a process but I'll > > investigate > > > > Regards, > > > > Hervé > > > > Le lundi 7 janvier 2019, 22:18:50 CET Christofer Dutz a écrit : > > > Hi Alex, > > > > > > Ways to do bad stuff with just a pom.xml: > > > - simply adding a dependency to a vulnerable library, even an > > > intentionally > > > staged malicious one. > > > > - Adding an evec-maven-plugin to execute anything on > > > > > the host machine - Generate code > > > - Like I introduced into the FlexJS maven build: Patch/Modify source > > > files > > > Guess the is what I could think of in 5 minutes... > > > > > > Ways to do bad stuff by just changing one-line versions: > > > And changing the version of a dependency to a known vulnerable version > > > would be such a one-liner. > > > > I'm currently introducing vulnerability checks into > > > > > all of my builds, so I'm bumping dependencies to unvulnerable versions > > > ... > > > doing this the other way around would introduce vulnerabilities. > > > > > > Connectivity problems: > > > Regarding network problems ... on my way to Montreal I staged the first > > > RC > > > for Apache PLC4X in a plane ... > > > > it took about 3 hours to upload cause of > > > > > network problems and latencies. Maven usually works around connectivity > > > problems quite nicely and reliably. > > > So all in all I would suggest you sort out the problems in the build > > > with > > > someone with experience. > > > > I already told Carlos how he could deploy to a > > > > > local directory during the release itself and then use another plugin to > > > stage that release independently. > > > If it aborts, you just re-start the deployment and close the repo as > > > soon > > > as all passes. > > > > > > Chris > > > > > > Am 07.01.19, 19:39 schrieb "Alex Harui" <[email protected]>: > > > Hi Greg, > > > > > > Thanks for the history. I agree with the general problem, however, > > > for > > > > > > Royale, I think the problem is constrained, but I could be wrong. I > > > don't > > > think there are exploits from things like missing semicolons and other > > > code > > > exploits that can be executed against pom.xml files, so the Royale > > > reviewers are first looking to see if bot changed any other files. > > > Maybe > > > Maven experts can tell us what kinds of exploit could be hacked into a > > > pom.xml. > > > > > > Could you answer another question? What is the current state of > > > SVN/Git > > > > > > integration? Could we spin up an SVN clone of our Git repos, restrict > > > the > > > bot via SVN, then sync back from SVN to Git (all from Jenkins)? > > > > > > Thanks, > > > -Alex > > > > > > On 1/7/19, 10:30 AM, "Greg Stein" <[email protected]> wrote: > > > On Mon, Jan 7, 2019 at 12:23 PM Alex Harui > > > > > > <[email protected]> wrote: > > > >... > > > > > > > > I still don't get why allowing a bot to commit to a Git repo > > > > isn't > > > > auditable. The changes should all be text and sent to > > > > commits@ > > > > and the > > > > RMs job is to verify that those commits are ok before putting > > > > the > > > > artifacts > > > > up for vote. I'd even try to make an email rule that > > > > > > checks for commits from buildbot and flags changes to files > > > > that > > > > are outside of what we expected. > > > > > > The historic position of the Foundation is "no ability to commit > > > > > > without a > > > > matched ICLA". That is different from "we'll audit any commits > > > > > made by $bot". The trust meter is rather different between those > > > positions, > > > specifically with the "what if nobody reviews? what if a commit is > > > missed? > > > what if that added semicolon is missed, yet opens a vuln?" ... With the > > > "matched ICLA" position, the Foundation has the assurance of *that* > > > committer, that everything is Good. ... Yet a bot cannot make any such > > > assurances, despite any "best effort" of the PMC to review the bot's > > > work. > > > > > > It is likely a solvable problem! My comments here are to outline > > > history/policy, rather than to say "NO". These are just the > > > > > > parameters of > > > > the problem space. > > > > > Cheers, > > > -g > > > InfraAdmin
