# CI: Providing builds on pull requests **URL:** \ **Category:** Development & Design\ **Created:** [June 15, 2023, 3:41pm UTC](https://forum.openrefine.org/t/ci-providing-builds-on-pull-requests/820 "2023-06-15T15:41:41Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![abbe98](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.openrefine.org/abbe98/32/1299_2.png) [@abbe98](https://forum.openrefine.org/u/abbe98)\ **Post date:** [June 15, 2023, 3:41pm UTC](https://forum.openrefine.org/t/ci-providing-builds-on-pull-requests/820/1 "2023-06-15T15:41:41Z")
To make it easier for non developers to test ongoing work it would be very nice if the CI could generate builds on pull requests. As someone working quite a bit on the GUI it would also be nice to be able to gather more input when making changes that affects things like design and existing behavior. It probably shouldn’t be the default CI behavior on pull requests but rather something that could be triggered by a collaborator adding a tag or comment. Thoughts? ---
**Author:** ![thadguidry](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.openrefine.org/thadguidry/32/653_2.png) [@thadguidry](https://forum.openrefine.org/u/thadguidry)\ **Post date:** [June 15, 2023, 8:58pm UTC](https://forum.openrefine.org/t/ci-providing-builds-on-pull-requests/820/2 "2023-06-15T20:58:34Z")
CI means continuous integration. With that it implies a strong preference to integrate new code, build, test. And to do so on each PR in order to give confidence in not breaking the build and maintaining confidence. GirHub provides excellent general documentation on best practices which we already basically follow. But perhaps you meant “build a binary and offer for download “? That could be added to PRs sure but is it really necessary since most devs locally will already be doing a refine build and running the binary and testing? ---
**Author:** ![thadguidry](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.openrefine.org/thadguidry/32/653_2.png) [@thadguidry](https://forum.openrefine.org/u/thadguidry)\ **Post date:** [June 15, 2023, 9:00pm UTC](https://forum.openrefine.org/t/ci-providing-builds-on-pull-requests/820/3 "2023-06-15T21:00:09Z")
Ah you said “non developers” ---
**Author:** ![antonin\_d](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.openrefine.org/antonin_d/32/32_2.png) [@antonin\_d](https://forum.openrefine.org/u/antonin_d)\ **Post date:** [June 15, 2023, 9:12pm UTC](https://forum.openrefine.org/t/ci-providing-builds-on-pull-requests/820/4 "2023-06-15T21:12:05Z")
There is this previous thread about mostly just that, no? > [@Helping users test PRs before they are merged](https://forum.openrefine.org/t/helping-users-test-prs-before-they-are-merged/230): > > Compiling OpenRefine from source is not so easy: you need to have some familiarity with git, and install and configure Java, Maven and NPM on your machine. I feel like the introduction of snapshot releases has had an interesting and positive impact on the project: because they are easier to install than compiling the tool from source, we have more people trying out new features before release. This is hard to quantify precisely of course, but I am hopeful that we see a fairly straightforward 3.… I think providing built packages for specific PRs could be doable, with a tag or message. The artifacts could be stored as workflow artifacts. ---
**Author:** ![abbe98](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.openrefine.org/abbe98/32/1299_2.png) [@abbe98](https://forum.openrefine.org/u/abbe98)\ **Post date:** [June 16, 2023, 2:47am UTC](https://forum.openrefine.org/t/ci-providing-builds-on-pull-requests/820/5 "2023-06-16T02:47:52Z")
ah there it’s! Thanks.