I use Bitrise for building some open source projects for the OpenID Foundation, and we frequently receive pull requests from external contributors. We have very strict code quality and conformance checks that are run on Bitrise which often fail for these pull requests, but the contributors are not able to see the logs to understand why.
Could it be made possible to allow users external to an app’s team to view builds and build logs?
My project is open-source. I would like to use bitrise to show every interested developer how to build the app by publishing the bitrise workflow.
Thanks for the #feature-request (@iainmcgin) and the additional info (@PhilippC)!
This is definitely on our roadmap, but we don’t have an ETA for it just yet, votes & comments are really appreciated 
We also really need this feature. If you have any love for open source projects, you really need to make this possible! Otherwise no open source project will use your service and you will not get known amongst the open source community.
Personally, I don’t believe you will ever do this due to server costs. Since this is still not done, I’m pretty sure this is a strategic decision. This feature was requested a long time ago by many developers but you’re just saying “yes, sometime” but nothing is done actually. I’m sure implementing at least a basic support for showing some information to the user when the project is set to be “public” shouldn’t be too much work.
For example you could add a step that uploads the build log to some server and posts the link to it in the pull requests that are failing. This is the very least I’d expect if you really care about open source developers. For public projects we would then simply need to add this step to the workflow and that’s it.
@jamitlabs that would be a temporary hack which we’re not committed to do. What we’re committed to do is to actually provide this feature in the future, but the right way, which is quite complex.
Just an example, we have to make sure that no private info is shared in those logs, as well as adding features so that if you accidentally share private infos in a public log you can remove the log, affected artifacts etc. as soon as possible.
We will not provide a “just show your log” type of solution because we do believe that would lead to tons of accidental secure info inclusions in the logs.
What we do, however, is adding related features which are prerequisites for this one, e.g. allowing builds / build logs to be deleted, public artifacts to be made private etc. Those are all on our roadmap and we definitely do plan to have public apps/logs eventually, but only when we can say with certainty that we have everything required to prevent accidental secure data inclusion in logs as well as have all the tools for you to correct the issue if it would still happen.
I hope this makes sense, questions are welcome as always.
I don’t see how the new step is a “temporary hack” – it’s not.
Your concerns about “accidentally sharing private infos” don’t apply to open source projects. What private info do open source projects have? None! Everything is developed in the open. I think you’re talking about other use cases, not the one for open source projects. Also the step would be opt-in, so people who use it will be aware of it.
This pull request on GitHub for example fails and the committer can’t see the log file. This is a serious problem. The suggested solution would completely solve it. It may be improved later on, but I don’t see a “security issue” in any way. What “private data” should be in the logs?
Just an example of a possibly dangerous leak which might slip through if you’re not “security aware”, and we plan to add some additional checks around: a read-write SSH key.
Why would you use one? Because there are countless popular tools which can help you with e.g. bumping build numbers, committing the change and pushing back.
Another example might be a GitHub OAuth token, which you might want to use for http://danger.systems/ integration or communicating back to GitHub in any other way.
Ideally none of course 
But you’d be amazed what kind of things we see in logs sent to us for inspection / debugging.
So, what you’re basically saying is that the users are not smart enough to be given the option to make their logs public because some of them don’t care enough about security. Well, I’d like to have the responsibility on my side. Again: It’s opt-in and you could add a warning to the step.
And if you really care about security, there’s an easy solution: Just add the option to the step to strip out specific Strings and let the user decide which those are. For example if I had a read-write SSH-key, I’d simply add it to the list of Strings to be stripped from the exported log. This should be easy to implement and allow us to work publicly with Bitrise very soon, not “sometime”. If there’s a security issue then, it’s the users fault. He opted in, saw a warning and didn’t add the sensible data to the ignore-list.
No, but we have to be cautious as much as possible which means e.g. that compromised logs, artifacts, etc. have to be removable, extra checks have to be added and warnings have to be placed on the UI, etc.
That said, if you want to, feel free to create a step or script to share back your log, e.g. as a comment on the related GitHub PR. That definitely should be possible, probably easiest with Danger ( Danger! Danger! Uh, that is... Using Danger with Bitrise - Bitrise ) or similar.
A small step towards this feature has been released: users can now delete the log of the builds permanently:
It’s been 8 months. Any update?
It’s in an invite only, private beta phase. Will be available once we’re happy with all the details & covered all the security related concerns this feature will bring (e.g. to prevent users to accidentally expose SSH keys).
It shouldn’t take long now to make into public beta, but if you’d want to get into the private beta today just let us know, would love your feedback!
Probably the fastest is if you DM me on our Slack: https://chat.bitrise.io/
We forgot to share the good news here - public apps is now GA, no need to join any private beta.
It also grants a dedicated free concurrency to the app if registered as a Public App.
We also rolled out a couple of security features to help with protecting Public Apps against misconfiguration:
Thank you all for your feedback & patience, we worked a lot on this to make it possible and your feedback helped a lot!
Happy Building! 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.