Just have a look at the Jenkinsfile of the PLC4X projects develop branch. The build has an additional Parameter: -DaltDeploymentRepository=snapshot-repo::default::file:./local-snapshots-dir clean deploy
The deploy step then use the wagon plugin to upload. You'll figure it out the rest ... Chris Outlook for Android<https://aka.ms/ghei36> herunterladen ________________________________ From: Hervé BOUTEMY <[email protected]> Sent: Tuesday, January 8, 2019 2:49:19 AM To: [email protected] Subject: Re: Can we package release artifacts on builds.a.o? ok, the issue for log4net is different than Royale a few thoughts: - perhaps you should limit your targets, since some targets look really old: this would decrease the number of configurations needed for the RM - I suppose the official source release artifact is the same for every platform: it's only the convenience binaries that require the platforms, and the requirement is not only for building but also for testing. Perhaps the efforts on convenience binaries should be decoupled from source, eventually with waves of binaries = make binaries available for a few recent 1st class platforms during the release, then other platforms available later based on feedback and help got from the community Choosing to support so many platform version, with very old ones, comes at a price: IMHO, making efforts to reduce supported scope will help you And if old platforms are really badly needed by many users, these users could be turned into contributors for the builds my 2 cents... Regards, Hervé Le lundi 7 janvier 2019, 13:23:59 CET Dominik Psenner a écrit : > On 2019-01-07 08:51, Alex Harui wrote: > > The workflow I envision is this: > > > > 1. RM runs Jenkins job on builds@ to create release branch, generate > > artifacts , tag the repo, push artifacts to Nexus staging and > > dist.a.o/dev/Royale 2. RM downloads artifacts to verify them, adds PGP > > signature and calls for vote 3. PMC downloads artifacts, verifies that > > the source packages matches the tag and performs other checks required by > > ASF release policy. > This roughly matches the vision I have for log4net, a subproject of the > apache logging pmc. log4net targets several .net frameworks (.net 2.0, > .net 3.5, .net 4.0, .net 4.0 cp, .net 4.5, netstandard 1.3, mono 2.0, > mono 3.5) and shall run on both linux and windows operating systems. > Requiring a developer to arrange at least four machines to maintain the > source code is off the table. Further the onboarding procedure for new > committers shall be as painless as possible. Otherwise it makes it just > harder to grow the community. So far we managed to build and test the > source code using jenkins on a sensible array of environments. I was > able to implement that pipeline because I had to stay in bed for two > months to heal some wounds. During this period I was able to work on > this for an hour or two each day. Currently we do have a release branch > and the binaries were built by jenkins. We currently lack the human > resources to test these binaries, even though I have great confidence > that the binaries work. If we had ready-to-use environments it would be > a great addition to the project. It would allow us to continue with step > 2 of the above workflow. I do however have no idea how this could be > achieved. Docker could be a piece of the puzzle, but not for the ancient > .net frameworks mentioned earlier. Last but not least I do hope that the > efforts put into the building and testing automation attracts new > developers and allows the project to continue existing. The alternative > is stagnation and becoming obsolete over time.
