I put the filter there as a test. I wanted only one file uploaded once and the same file is uploaded 157 times instead. It stopped after 67 because I aborted.
I’m interested to know what has changed to make this loop 157 times. I think it’s important to find out. From: Alex Harui<mailto:[email protected]> Sent: Friday, May 1, 2020 12:14 AM To: [email protected]<mailto:[email protected]> Subject: Re: wagon:upload problems The filter is so the RM only uploads .asc files, but I think there is one for every SWC. Seperately, the CI server will try to upload everything else. -Alex On 4/30/20, 1:52 PM, "Christofer Dutz" <[email protected]> wrote: I think I can tell you what's happening :-) You're running the wagon:upload in a maven reactor. This means it's executed once for every module in the reactor. Unfortunately you're giving the order to deploy the entire tree for every artifact in the reactor. So that's the reason why it's happening so often. I guess that was the main reason for PLC4X we simply put it into a separate pom (we just called it jenkins.pom). You can however force maven to just build selected modules (and hereby execute the plugin only once in there), by adding "-pl royale-framework-parent" to the command. But there's a second problem: From the log output I can see the script is using an include pattern: includes = **/*.zip.asc Unfortunately (regarding your bill probably rather "fortunately") there is only one artifact in the directory tree for which this pattern matches and that's the source release's signature file. All others would be **/*.xml, **/*.swc and alike. That's the reason why it's trying to deploy that file so often. Chris Am 30.04.20, 21:49 schrieb "Alex Harui" <[email protected]>: Hi Chris, As I understand it, Yishay is only running one Wagon call. The Jewel calls are not being run, but in that one Wagon call, the source-release for the parent is being uploaded many times and it doesn't look like it is trying to upload the artifacts. Check out the log he posted at [1]. How did we give the commands incorrectly that caused it to do what it did? [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Ftpdkh&data=02%7C01%7Caharui%40adobe.com%7Cc397e47fa36943945e1208d7ed486533%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238767506916483&sdata=LOnTh6Ty9WnoqVwTpydZprko5yD4rwizrc0nExFIFI4%3D&reserved=0 On 4/30/20, 12:41 PM, "Christofer Dutz" <[email protected]> wrote: Hi folks, Just to try it out ... almost anyone that has setup his credentials in the settings.xml could try to deploy asjs by running: mvn clean deploy -Papache-release,apache-release,with-distribution,option-with-swf On the develop branch. It would automatically build the same artifacts, sign them and instead of creating a staging repo, would upload them to the SNAPSHOT repo. Would be really interesting on if you really are having these upload problems. And I mean anyone could test this without having to be RM. It's just one command, nothing more and you can't even mess up anything as the code isn't changed. And by the way ... the releasesteps.xml does actually deploy a large portion of the artifacts multiple times ... The ant target uploadSWCs already deploys the entire artifact tree ... there's no need for uploadJewelDark and uploadJewelLight Chris Am 30.04.20, 20:43 schrieb "Alex Harui" <[email protected]>: Gee I hope that didn't cause that IP to be blocked by Apache. Keep that in mind if you have trouble uploading from the CI server next time you try. Find the IP address of the CI server and ask Infra if it got blocked. There is a chance that Azure blocked as well. I guess I'll find out if I have to pay Azure a huge bandwidth overage bill or not. It does tell us something about the reliability of the connection on a windows machine in the US vs your computer outside the US. Anyway, I think you can test locally with the .asc files and figure out the right params. Good luck, -Alex On 4/30/20, 11:34 AM, "Yishay Weiss" <[email protected]> wrote: I suspect this might be related to recent maven profile changes not meshing well with the release script targets. I’ll see what I can dig up. From: Yishay Weiss<mailto:[email protected]> Sent: Thursday, April 30, 2020 9:32 PM To: [email protected]<mailto:[email protected]> Subject: RE: wagon:upload problems >I think it might be repeating the upload for each project. Upload happens 67 times [1] in a loop. That explains why even on the CI server after 5.5 hours it finally failed [2]. [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Fzh3rj&data=02%7C01%7Caharui%40adobe.com%7Cc397e47fa36943945e1208d7ed486533%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238767506916483&sdata=bV0ZNyBl0HaKo6LCgD3M835qHzRef3CwMdQVgvcrKto%3D&reserved=0 [2] [exec] [INFO] BUILD FAILURE [exec] [INFO] ------------------------------------------------------------------------ [exec] [INFO] Total time: 05:36 h [exec] [INFO] Finished at: 2020-04-30T18:01:58Z [exec] [INFO] ------------------------------------------------------------------------ [exec] [ERROR] Failed to execute goal org.codehaus.mojo:wagon-maven-plugin:2.0.0:upload (default-cli) on project Effects: Error handling resource: Failed to transfer file http s://repository.apache.org/service/local/staging/deploy/maven2/org/apache/royale/framework/Jewel-Light-NoFlat-Emphasized-Emerald-Theme/0.9.7/Jewel-Light-NoFlat-Emphasized-Emerald-Th eme-0.9.7-js.swc with status code 400 -> [Help 1] [exec] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:wagon-maven-plugin:2.0.0:upload (default-cli) on project Effects: Error handling resource
