Allow public read-only access #137
Comments
This is also an issue for us. We need the ability to share build output with unauthenticated users who may be able to see PR build failures but not have an account on Buildkite. |
Over the last few months we've been refactoring our data access layer to support public builds. Most of this is done now, and it's now possible for us to add this feature (before it was close to impossible). The only things for us to figure out now is the scope of the feature. Here are some things that may be in scope for this feature:
That's a bit of brain dump about public builds, and the things we need to think about. I'm keen to open up the discussion to you folks to see what you think! Obviously, the less that's in scope for this feature, the easier it is to ship, but since this can cause some security issues, I don't want to rush it. |
In my case all the PR builds require my intervention before they run (a no-op followed by the continue/lock). I have separate projects/pipelines for PRs/pushes. I have no sensitive thing whatsoever. I just want them to have read-only access to the build pages (even for non-PRs), no canceling needed or anything. About educating users, I suppose the same kind of warning as the one for building third party PRs is required. The most sensitive is the building part anyway, that's where anyone could put any code and run it on your machines. Perhaps make a mandatory manual confirmation (like what I already do) and/or have a whitelist would be useful. |
How are you keep those builds secure on your machines out of interest? Happy to talk more about it in Slack in a DM if you don't want to talk about it here. The manual confirmation when they turn this feature on I think is a good idea! A bit like how when you delete a repo on GItHub, they require you to re-enter the name of the repo. Another thing I just though of is the |
I read the PR before I run the builds. :-) Most PRs are small so any malicious intent is quickly detected. The repos do not contain any BuildKite configuration either it's all done from the site so there's little that can be broken. |
@lox has also done work on the Buildkite AWS for securely running third party PRs, we have some technology |
*Buildkite AWS Stack |
Any update on this? In the bioconda project (https://github.com/bioconda), we need people to see the build log publicly. |
We'd also like to use Buildkite for an open source project we have coming out; We're less worried about full features, but mostly being able to see a build-log via a public url. Is a solution for open source projects something coming "soon"? Thanks! |
@johanneskoester @pquerna howdy! Sorry for the reply. This is on our roadmap and we're working on it in an upcoming cycle. Watch this space! 🔜 |
@keithpitt That's great, thanks! Can you give us a rough estimate how soon? Within weeks or months? I am asking because I will work on a workaround if it takes more than weeks. |
what is the status of this ? being able to provide read-only access would be most helpful ! |
@johanneskoester @prudhomm this is still high on the cards, but nothing to show yet sorry! |
Any update on this @toolmantim? :) |
@schickling not yet sorry, but we’re working on it |
One of main challenges here is to provide a good security story when builds use some sensitive information from agents. |
You probably shouldn't be logging output in that case? I do think that the environment variables tab will probably need to be hidden for unauthenticated builds, and also probably something like #293 solved to enable this in a secure way for pull requests. |
I think there are different stages at which this feature can be provided. I believe the simplest to start would be to make it suitable only for builds that
I believe this would already cover 95% of open-source builds. More sophisticated use cases could be added later, but right now many people cannot use buildkite because it is essentially useless for public builds of open-source projects. |
What @nh2 said. Next set could be buildkite github bot that triggers builds per github authd users through comments. |
I agree it can easily be done for builds that do not use any form of secrets, but I think that should include PRs. I already run public PRs automatically and have a step that requires me to click something in BuildKite to make it continue. This click should be only for users with the right credentials (it probably already checks them) but everything else can be public. |
|
Hey everyone, thanks for the ideas/thoughts :) The good news is, we're actively working on this and having to have beta out soon. You're right in that it's a little tricky because we want to ensure we've got a good store to tell around security and abuse, and we're hoping to have all the rough edges ironed out for a beta soon. We'll drop everyone a line here when were' looking for testers! |
Yay! We would also love to have this! |
Looking forward to the beta. |
I would really like it if there were some piece of documentation that told me something like "if you set your secret inside an environment variable with We're intending to allow external contributions to some open source codebases, and so while we absolutely want those contributions to benefit from CI and reading the logs so they can self-service debugging, we'd prefer to minimise the amount of contribution-reading it's necessary to do before allowing a build to run. |
We (https://sourcegraph.com) would like to open-source some repositories that we use Buildkite for, including our popular Sourcegraph browser extension. We are comfortable with beta stuff and putting in some extra work to do this. We would also be happy to blog about it and help spread the word about how awesome Buildkite is if this is possible soon. The alternative is that we'd have to eventually switch to Travis CI or CircleCI. You can email me at sqs@sourcegraph.com to hash out details. |
In the meantime, one idea could be to use something like https://github.com/uw-ipd/github-checks-buildkite-plugin to publish checks for your builds? 🤔 |
👍 The Prometheus open source monitoring project would be very interested in being able to share build output. We have many non-core contributors that can't see why their builds fail so we have to proxy build output for them. This wastes everyone's time. 😢 |
FWIW I recently wrote a little heroku-based front end to buildkite that enables 3rd party contributors to view buildkite logs/artifacts from their pull requests: https://github.com/mvines/ci-gate Additionally project maintainers need to approve these 3rd party PRs for CI by adding a label (presumably once they’ve confirmed the PR isn't malicious). Maybe others will find my project useful until buildkite can support this use case natively. |
Hey there everyone! 👋🏼 Just a quick one with some news on Buildkite public builds! We’ve been busy working away on getting an initial version ready for prime time, and are currently ramping up towards making it generally available. However, given the amount of community interest in this feature, we’re also really keen to make sure we have time for feedback, and allow interested parties to kick the tyres a bit beforehand. If you’re interested in getting into the beta group checking public builds out, please jump over to our community forum, sign up and shoot through a message asking for access — we’ll help get you set up from there! 🎉 |
Great start! Any information on what's planned for gating third party builds? ci-gate has some great ideas behind it, it would be really great if Buildkite could adopt something like this. |
@KevinGrandon Hey, thanks! We’re just getting started with support for public builds so the focus right now is just starting to open things up. The longer term goal absolutely being awesome support and tooling around testing third-party contributions and supporting OSS. We’d be very interested in hearing about specific workflows or use-cases in this space on the forum to help us shape this work! |
https://buildkite.com/changelog/46-public-build-pages-for-open-source seems to indicate this is possibly fixed? |
Hey y’all—my apologies I think this one slipped through and I forgot to close it! D’oh! 😅 As @palfrey noted we shipped support for public read-only pipelines a little while ago, and so far it seems to have been ticking along really nicely! We’ve also been lucky enough to have a few pretty large projects, as well as many, many other smaller teams help us kick the feature around, and it’s now been generally available for a few months! 🎉🥳 I’m going to close this issue out, but we’d still love to hear any feedback you may have on the forum! 🙂 |
I would like to give read-only access to my users, at least for builds coming from pull requests. Right now they can't check the reasons for failure from the link in the PR.
The text was updated successfully, but these errors were encountered: