search

a7ex / xcresultparser

Parse the binary xcresult bundle from Xcode builds and testruns
MIT License
98 stars 28 forks source link

Binaries attached to releases #11

Closed hisaac closed 1 year ago

hisaac commented 1 year ago

Would it be possible for you to add binaries to the releases here on GitHub? It would be helpful for a workflow we're using at my job.

a7ex commented 1 year ago

Hi Isaac, I tried to create the binary in the GitHub action, but the problem is that it is not notarised and therefore is not really safe to run on a different machine. Last time I tried notarising another app I was not very successful. Do you have any hints?

hisaac commented 1 year ago

I don't know offhand, but I can do some googling. Looks like you've added a new GitHub workflow, so maybe you've figured it out? Let me know if you ned any help testing.

a7ex commented 1 year ago

The actions have attachments. The attachment is the binary. You can try those. They are not notarised and thus from "an unknown source". Not exactly, what I would want to publish. Therefore I distribute it as source and brew takes care of the rest. We use brew in our buildchains. Why can't you download and build from source or have brew handle that for you?

hisaac commented 1 year ago

Gotcha, I'll do some experimentation on my fork and see if I can come up with something workable.

As for using brew, for our build system, I prefer to download specific versions of our tools so we know exactly what we're getting. brew doesn't allow for that, unfortunately. That'd make life way easier.

hisaac commented 1 year ago

ok, I did a bit of a deep-dive on this notarization thing, and have learned some interesting information!

So when you download a binary using a browser, the browser adds "quarantine flags" to the item, which tells macOS that the user has to explicitly approve running it, hence the "an unknown source" popup.

BUT, there are a few workarounds:

  1. If you download the item using curl or wget or similar, it does not set those quarantine flags.
  2. If the item being downloaded is a tarball — .tar, .tar.gz, .tar.xz, etc. — unarchiving that using the tar binary strips off the quarantine flags.
  3. You can explicitly remove the quarantine flags after downloading by running the following command: 
    xattr -rd com.apple.quarantine "/path/to/xcresultparser"

All that said, perhaps a good way forward would be to archive the binary as a tarball for the release artifacts, and add a note to the README summarizing what I've got above. What do you think? I'm interested enough to do said work if you're open to the change.

hisaac commented 1 year ago

Also, side note, I'd recommend also archiving the Actions artifacts prior to uploading them. The upload-artifact action has an annoying side effect of stripping some data from the files, namely in this case, the binaries executable permissions — as in, you have to chmod +x xcresultparser the downloaded binary.

The suggested workaround is to archive as a tarball prior to uploading.

hisaac commented 1 year ago

I see you got it notarized! Even better! 🙌

Can I ask how you did it? I couldn't figure it out from my googling around.

a7ex commented 1 year ago

There is no a shell script in the Repo. Code tells so much more than words... :-)

On 28. Apr 2023, at 12:30, Isaac Halvorson @.***> wrote:

I see you got it notarized! Even better! 🙌

Can I ask how you did it? I couldn't figure it out from my googling around.

— Reply to this email directly, view it on GitHub https://github.com/a7ex/xcresultparser/issues/11#issuecomment-1527348373, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANBA4VH76MOXG5PCKNVVNDXDOL2XANCNFSM6AAAAAAXMLZ7PI. You are receiving this because you commented.

hisaac commented 1 year ago

Oh I don't see the shell script 🤔

a7ex commented 1 year ago

ups...? Did I only dreamed I committed - again... :-)

On 28. Apr 2023, at 15:33, Isaac Halvorson @.***> wrote:

Oh I don't see the shell script 🤔

— Reply to this email directly, view it on GitHub https://github.com/a7ex/xcresultparser/issues/11#issuecomment-1527571484, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANBA4S5F62QQC5CAXBFOVLXDPBKHANCNFSM6AAAAAAXMLZ7PI. You are receiving this because you commented.

a7ex commented 1 year ago

There you go...

On 28. Apr 2023, at 15:33, Isaac Halvorson @.***> wrote:

Oh I don't see the shell script 🤔

— Reply to this email directly, view it on GitHub https://github.com/a7ex/xcresultparser/issues/11#issuecomment-1527571484, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANBA4S5F62QQC5CAXBFOVLXDPBKHANCNFSM6AAAAAAXMLZ7PI. You are receiving this because you commented.

hisaac commented 1 year ago

This is awesome! Thank you, and great work!

a7ex commented 1 year ago

You are very welcome. I am glad, that my little tool ist useful for you.

And in fact it plays an important role in our build chain, not only to display the tests, but more important to send the results to sonarqube with coverage and testresults. For the former there is a tool, which is just very slow, but for the latter (sending test results) there is nothing, because xcresult is not compatible out of the box.

On 28. Apr 2023, at 16:42, Isaac Halvorson @.***> wrote:

This is awesome! Thank you, and great work!

— Reply to this email directly, view it on GitHub https://github.com/a7ex/xcresultparser/issues/11#issuecomment-1527674260, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANBA4QH4TJOC66LDUNKHW3XDPJOFANCNFSM6AAAAAAXMLZ7PI. You are receiving this because you commented.

hisaac commented 1 year ago

Nice, we're using it in a similar fashion. We're now pre-converting our code coverage from .xcresult to Cobertura XML before sending it to Codecov. Codecov does do the conversion for us if we just sent the .xcresult, but it's way slower than doing it ahead of time using xcresultparser. 🚀

a7ex commented 1 year ago

I know. It is a bit of a hassle to get coverage out of xcresult. You need to call the xccov tool, which comes with Xcode, for each file! And as described as compiled app, we can spawn the calls to more than one thread and so they execute in parallel. I am surprised, that there aren't more tools to get the coverage out of xcresult. All of them use the same shell script, which can not spawn the work on parallel threads.

The good thing in our job: We can (often) just create our own tools! :-)

On 28. Apr 2023, at 17:54, Isaac Halvorson @.***> wrote:

Nice, we're using it in a similar fashion. We're now pre-converting our code coverage from .xcresult to Cobertura XML before sending it to Codecov https://codecov.io/. Codecov does do the conversion for us if we just sent the .xcresult, but it's way slower than doing it ahead of time using xcresultparser. 🚀

— Reply to this email directly, view it on GitHub https://github.com/a7ex/xcresultparser/issues/11#issuecomment-1527765183, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANBA4RJHLS3K7D2YDX5GNTXDPR2LANCNFSM6AAAAAAXMLZ7PI. You are receiving this because you commented.