Groups in workspace with paths relative to `container:` not being handled

[kjcjohnson]

We're seeing a project not being able to be found by the workspace parser. It looks to me like it's related to handling of the location property of Groups. Workspace snippet:

<?xml version="1.0" encoding="UTF-8"?>
<Workspace
   version = "1.0">
...etc...
   <Group
      location = "container:Modules"
      name = "SomethingElse">
      <FileRef
         location = "group:MyProject/MyProject.xcodeproj">
      </FileRef>
      <Group
         location = "container:Modules"
         name = "Modules">
         <FileRef
            location = "group:FeatureA/FeatureA.xcodeproj">
         </FileRef>
         <FileRef
            location = "group:FeatureB/FeatureB.xcodeproj">
         </FileRef>
...etc...

The first problematic reference that gen-ir can't find is MyProject.xcodeproj. Unclear if it would find FeatureA and FeatureB projects if it got that far. On disk, the project layout is:

MyWorkspace.xcworkspace/
...
Modules/MyProject/MyProject.xcodeproj/
Modules/FeatureA/FeatureA.xcodeproj/
Modules/FeatureB/FeatureB.xcodeproj/
...

If I were to guess, the suspicious part seems to be that the location attribute of the group has a part after the colon: container:Modules, which apparently sets the root path of the group to Modules/. These groups are the only groups I see it in; everything else is just container:. My reading of XcodeWorkspace.swift implies that only prefixes of group: are handled, for both Groups and FileRefs, not container:.

I'm not sure how to set this up in the most recent Xcode UI (this is a really old workspace), so you have to edit the workspace file directly. Both Xcode and the xcodeproj Ruby gem handle group locations this, so it seems like a legitimate thing. I don't have a great "sanitized" minimal reproduction, sorry. Let me know if it would be useful.

[NinjaLikesCheez]

First off - thank you for such a detailed report! It really helps narrow down the issue and the amount of prep work needed. I am also unable to replicate this in the Xcode UI, but editing the workspace file manually did indeed get me there - is the Xcode Project generated by a third-party tool out of interest?

Regardless, you are correct in your suspicions. I'll improve the handling in this situation to cover this case.

[NinjaLikesCheez]

I've pushed a change in https://github.com/veracode/gen-ir/tree/workspace-container-fixes that should resolve this - if you could build this branch and run it against your project to see if it fixes your issue that would be great. Thanks!

[kjcjohnson]

Hmm, it's getting hung up somewhere else now with container: tags. Snippet:

<Workspace
   version = "1.0">
   <Group
      location = "container:"
      name = "Infrastructure">
      <Group
         location = "container:"
         name = "Widgets">
         <FileRef
            location = "group:Infrastructure/Foo/Foo.xcodeproj">
         </FileRef>
      </Group>
...

It's looking for the project at Infrastructure/Widgets/Infrastructure/Foo/Foo.xcodeproj, instead of just Infrastructure/Foo/Foo.xcodeproj.

[kjcjohnson]

is the Xcode Project generated by a third-party tool out of interest?

No, it's just really old, so I suspect this was supported in some early version of Xcode. Or maybe just in a merge conflict or someone being "clever" over the years.

[NinjaLikesCheez]

Sorry for the late reply - end of conference season.

I've rewritten workspace project discovery to make it a little more flexible that should resolve your recent issue. It does require additional testing (including writing a test) and some research to see if I can dig out the format a little better from Xcode.

[kjcjohnson]

Apologies for the delay - right in the middle of my conference season. From my testing, looks like the updates in #50 do correctly process our workspaces! I will wait warmly for the release.

[NinjaLikesCheez]

This was released today as an alpha build of the 0.5.0 release - you can install it with brew install gen-ir@0.5.0-alpha. Thanks again for your report!