Marek Fořt

> This should help opt out of most settings except those that have properties defined in the Project / Target types, they will still leave overrides 🤐 Ahh, good point,...

> What do you think? We can take that code and add support for the endpoints for certificates and profiles. We can use Fastlane's Match codebase as a reference. Oh,...

> use the undocumented API that Fastlane's match has always been using I have been thinking about this and I think it might be better for us not to take...

Now that I have started tinkering with the implementation, it occurred to me that maybe a new command `vendor` might not be necessary. We can already tell if we should...

I'll continue dumping my thoughts here as I stumble upon problems during the [implementation](https://github.com/tuist/tuist/tree/signing_vendor) - there will be needed only one development/distribution certificate for one team and so it might...

Thanks for the feedback @pepibumur! > prompt the user for username and password this is not necessary, all that is necessary to generate a certificate/profile is API key that will...

Hi @lucasilverentand! Thanks for the interest 🖤 the biggest issue with vendor at the moment is the sync of certificates which are shared across the organization's projects. Therefore, a server-side...

> That would be great, I'm currently thinking of starting a dashboard for developers to manage their apps in one place, but that's still very much in the making. But...

> This uses print to output the error because ProjectAutomation doesn't import TuistSupport so I couldn't use a logger instance Indeed, you can't! > Should error handling happen within Task.swift...

Hi @jesus-qt! The issue with `init(from projects: Project)` is that we don't have access to projects - and we _can't_ have it AFAICT. While `var workspace = Workspace.default` should be...