Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JENKINS-58490] Support symbol files #37

Merged

Conversation

mezpahlan
Copy link
Contributor

Builds upon the good work from #30 by @Kilomoana83 . Supports symbol upload functionality. This is an alternative implementation based on the PR comments I left in the pull request. We will only merge one of them.

The main difference here is that this PR aims to support both IOS and Android symbol files and uses a different architecture of the plugin that is more in line with what existed.

@mezpahlan mezpahlan added the feature New feature label Oct 29, 2019
@mezpahlan mezpahlan force-pushed the JENKINS-58490-support-symbol-files branch from 76d0ded to a73d1fa Compare November 2, 2019 13:00
@carllindberg
Copy link

Is there a chance this (or the other one) will be committed and released before the HockeyApp execution date? Was hoping to be able to switch without (effectively) losing exception handling support, as that is mostly useless without the symbol files for iOS.

Also, not sure what the UI will be, but I would make the label "Apple dSYM" or something that mentions dsyms, as that is the name most would be familiar with.

@mezpahlan
Copy link
Contributor Author

@carllindberg That's the aim. However, I can't guarantee anything at this stage.

As for the UI it will be pathToDebugSymbols as we aim to support both Android and IOS.

@mezpahlan
Copy link
Contributor Author

OK anyone watching this is the pretty much how I see the symbols upload working. It should support both IOS and Android. However I haven't yet had time to a) write any unit tests or b) test this. I'll do that in a bit, but feel free to test this branch yourselves.

It seems like there's a lot of demand for this so I'd be happy to release this without the unit tests, but I do want to at least get some feedback from real users on both Android and IOS platforms. I can do Android, but I don't have a way of testing IOS so would appreciate that help.

@Kilomoana83

@mezpahlan
Copy link
Contributor Author

If you don't want to compile yourself then the you can grab the latest build from this branch here.

@Kilomoana83
Copy link
Contributor

I will give it a try today @mezpahlan
Ah, what a service. thanks :D

@mezpahlan
Copy link
Contributor Author

I've tested this with an Android app and it works well! I'm going to continue to write unit tests but will wait until I get an all clear from an IOS user.

This field is optional and should not error if you do not supply it.
@Kilomoana83
Copy link
Contributor

Sorry, wasn't able to find the time on Friday. Will do the iOS test today hopefully.

@Kilomoana83
Copy link
Contributor

As I am working on another machine today and got again stuck with the autogeneration not kicking in (not sure what's wrong with my setup), I have used the hpi from the PR to test.

What I found weird is that you get a red warning if you do not provide a symbols path. At it is optional, I would remove that warning, otherwise it could be a bit confusing to the user.

Besides that, from the logs it seem to have worked, but I do not see the Symbols:

File found matching pattern: build/xxx.ipa
Symbols found matching pattern: build/xxx.dSYM.zip
Creating an upload resource for app.
Create upload resource for app successful.
Creating an upload resource for debug symbols.
Create upload resource for debug symbols successful.
Uploading app to resource.
Upload app to resource successful.
Uploading symbols to resource.
Upload symbols to resource successful.
Committing app resource.
Committing app resource successful.
Committing symbol resource.
Committing symbol resource successful.

I do not think that I will have time today to look into the code, but I will try tomorrow morning.

@mezpahlan
Copy link
Contributor Author

Thanks @Kilomoana83. I appreciate the help. I noticed that too and have made a few changes to that screen whilst trying to write unit tests to the PR.

I think in the interest of time I'll do the unit tests in a separate PR soon after this but will incorporate any changes that mention from your tests tomorrow including the one above.

@carllindberg
Copy link

It worked for me as well. Uploaded, and I saw symbolicated backtraces in AppCenter with crashes. Thanks so, so much.

I will second Kilomoana83's point that it complains if the dSYM path is not supplied, when it should be optional. (It's possible to use AppCenter without using its crash-catching stuff.) Also, would probably be better to have the debug symbols path be right next to the app path in the Jenkins UI, not at the bottom (the values can be related or at least very similar).

My question on the label earlier was your SymbolType enum internally, but it appears that value does not get shown to the user, so that was moot.

Thanks again.

@michaljrk
Copy link

michaljrk commented Nov 15, 2019

Hello,
I gave it a try from the latest PR-37 branch build for my Mac app (migrated from HockeyApp), but it's failing unfortunately with the following error:

io.jenkins.plugins.appcenter.AppCenterException: Upload to AppCenter failed.
	at io.jenkins.plugins.appcenter.task.UploadTask.call(UploadTask.java:56)
	at io.jenkins.plugins.appcenter.task.UploadTask.call(UploadTask.java:17)
	at hudson.remoting.UserRequest.perform(UserRequest.java:212)
	at hudson.remoting.UserRequest.perform(UserRequest.java:54)
	at hudson.remoting.Request$2.run(Request.java:369)
	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:93)
	at hudson.remoting.Engine$1$$Lambda$4/1097897383.run(Unknown Source)
	at java.lang.Thread.run(Thread.java:745)
	Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to JNLP4-connect connection from XXXX.XXX-XXXXX-XXX.net/XXXX:XXXX
		at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741)
		at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
		at hudson.remoting.Channel.call(Channel.java:955)
		at hudson.FilePath.act(FilePath.java:1160)
		at io.jenkins.plugins.appcenter.AppCenterRecorder.uploadToAppCenter(AppCenterRecorder.java:156)
		at io.jenkins.plugins.appcenter.AppCenterRecorder.perform(AppCenterRecorder.java:143)
		at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:81)
		at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
		at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744)
		at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:690)
		at hudson.model.Build$BuildExecution.post2(Build.java:186)
		at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:635)
		at hudson.model.Run.execute(Run.java:1835)
		at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
		at hudson.model.ResourceController.execute(ResourceController.java:97)
		at hudson.model.Executor.run(Executor.java:429)
Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: Unable to determine application type and therefore debug symbol type
	at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
	at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1887)
	at io.jenkins.plugins.appcenter.task.UploadTask.call(UploadTask.java:54)
	... 11 more
Caused by: java.lang.IllegalStateException: Unable to determine application type and therefore debug symbol type
	at io.jenkins.plugins.appcenter.task.internal.PrerequisitesTask.symbolUploadRequest(PrerequisitesTask.java:110)
	at io.jenkins.plugins.appcenter.task.internal.PrerequisitesTask.checkSymbolsExist(PrerequisitesTask.java:94)
	at io.jenkins.plugins.appcenter.task.internal.PrerequisitesTask$$Lambda$17/892178062.apply(Unknown Source)
	at java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:981)
	at java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2116)
	at io.jenkins.plugins.appcenter.task.internal.PrerequisitesTask.execute(PrerequisitesTask.java:44)
	at io.jenkins.plugins.appcenter.task.UploadTask.call(UploadTask.java:42)
	... 11 more

Not sure where I should look at first to find the cause, any help would be greatly appreciated.

@mezpahlan
Copy link
Contributor Author

Hi @michaljrk

The exception is:

Unable to determine application type and therefore debug symbol type

We basically check the file extension to determine whether you're uploading an IOS app or an Android app. Really simply: ipa or apk.

Does that help?

@mezpahlan
Copy link
Contributor Author

Hi @Kilomoana83 did you get a chance to test this? I'd like to merge this if possible but wanted to wait for your OK first.

@mezpahlan
Copy link
Contributor Author

@Kilomoana83 if you're looking for where the mappings / symbols files are located via the AppCenter UI then I agree it isn't in the most obvious place but I have found mine under Diagnostics -> Mappings for my Android project. Maybe for IOS it is the same?

@mezpahlan
Copy link
Contributor Author

@carllindberg thanks for testing this. To answer your points:

I will second Kilomoana83's point that it complains if the dSYM path is not supplied, when it should be optional. (It's possible to use AppCenter without using its crash-catching stuff.)

This should be fixed now.

Also, would probably be better to have the debug symbols path be right next to the app path in the Jenkins UI, not at the bottom (the values can be related or at least very similar).

I have no preference on that. At the moment I want to fix a couple of more serious bugs before looking at the UI side of things which I am sure can be improved in line with your suggestion. If you don't mind could you raise a ticket for that in JIRA (instructions in the README) and I'll look at it when I have time (or someone else can once I've agreed the acceptance criteria). There's a few other higher priority issues that I want to resolve first though so if you can live with it at the bottom for now that might have to do for now.

And if I don't get a reply back by tomorrow from the original requester I'll go ahead and merge this on the strength of your test.

@michaljrk
Copy link

Hi @michaljrk

The exception is:

Unable to determine application type and therefore debug symbol type

We basically check the file extension to determine whether you're uploading an IOS app or an Android app. Really simply: ipa or apk.

Does that help?

Thanks for your reply @mezpahlan . That's the reason probably as I'm trying to upload macOS app using zipped format (*.app.zip). Any suggestions how to achieve that (it used to work with Hockey plugin).

@mezpahlan
Copy link
Contributor Author

Hi @michaljrk Oh I see. We don't officially support MacOS apps just yet. I think we probably should so could you raise a ticket in JIRA (instructions in the README) and I (or someone else) can look at how to add support.

@michaljrk
Copy link

Hi @michaljrk Oh I see. We don't officially support MacOS apps just yet. I think we probably should so could you raise a ticket in JIRA (instructions in the README) and I (or someone else) can look at how to add support.

Issue created:
https://issues.jenkins-ci.org/browse/JENKINS-60197

Thanks a lot!

@Kilomoana83
Copy link
Contributor

@mezpahlan hey, yes, sorry forgot to update. The displaying in appcenter could be better and is only displaying the symbols when there is a crash. The mapping view from Android does not seem to exist.

@mezpahlan
Copy link
Contributor Author

Thanks @Kilomoana83 I think at this stage it is now an issue with how AppCenter displays the symbol files for IOS only upon a crash. My reading of the IOS Symbolication page in the AppCenter documentation leads me to believe that this is as expected.

I'm happy to look into things again under a different JIRA issue in the future if things still aren't working but for now I think uploading of the symbols files is working for Android (based on my observations) and IOS (based on @carllindberg's observations).

I'll go ahead and merge this now. Many thanks for persisting with this. And sorry it took so long since you originally raised it.

@mezpahlan mezpahlan merged commit 2114c57 into jenkinsci:master Nov 18, 2019
@mezpahlan mezpahlan deleted the JENKINS-58490-support-symbol-files branch November 18, 2019 17:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature
Projects
None yet
4 participants