# Share builds via Bitrise CLI
**URL:** https://discuss.bitrise.io/t/share-builds-via-bitrise-cli/3940
**Category:** Released
**Created:** [January 29, 2018, 12:54pm UTC](https://discuss.bitrise.io/t/share-builds-via-bitrise-cli/3940 "2018-01-29T12:54:27Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Shashikant](https://discuss.bitrise.io/u/Shashikant)
#### Post date: [January 29, 2018, 12:54pm UTC](https://discuss.bitrise.io/t/share-builds-via-bitrise-cli/3940/1 "2018-01-29T12:54:27Z")
This is with respect to [Issue](http://discuss.bitrise.io/t/got-success-message-for-everything-in-bitrise-cli-locally-but-no-build-released/3870) , which I was trying to solve.
Why will we have to go to dashboard just to share builds?
---
### Author:  [@viktorbenei](https://discuss.bitrise.io/u/viktorbenei)
#### Post date: [January 29, 2018, 7:57pm UTC](https://discuss.bitrise.io/t/share-builds-via-bitrise-cli/3940/2 "2018-01-29T19:57:26Z")
Hi @Shashikant,
Can you please share a bit more details? A simple step-by-step description would be the best, about what you want to do š
---
### Author:  [@Shashikant](https://discuss.bitrise.io/u/Shashikant)
#### Post date: [January 31, 2018, 4:36am UTC](https://discuss.bitrise.io/t/share-builds-via-bitrise-cli/3940/3 "2018-01-31T04:36:26Z")
Hi,
I have come across Bitrise as an CI,CD Tool. It works very well and it is just what we actually want. But To do this, I have to manually go inside the dashboard and click on āStartā the build or schedule the build. Then it will generate the build.
What was my assumption, when developer writing the code and commit the code.
1. The code gets pushed or will create pull request, it will call triggers to create automated builds ( Have not tested this, bt my aasumption is that , this gonna work )
2. But what if developer directly want to create āReleaseā build directly from his machine and not going into the dashboard for which he didnāt have the access also. What he know is the command like ābitrise run releaseā and it will upload the build on iTunesConnect directly.
Conclusion is - Why there should be need to giving access of bitrise to the developer, or wait for pull request to be merged and approved. He should be directly able to send build from his machine.
I know it is breaking some of the standards but It was just my thoughts.
Thank you
---
### Author:  [@viktorbenei](https://discuss.bitrise.io/u/viktorbenei)
#### Post date: [January 31, 2018, 12:36pm UTC](https://discuss.bitrise.io/t/share-builds-via-bitrise-cli/3940/4 "2018-01-31T12:36:33Z")
> [@Shashikant](#):
>
> The code gets pushed or will create pull request, it will call triggers to create automated builds ( Have not tested this, bt my aasumption is that , this gonna work )
Indeed, this definitely works if you have a Webhook registered in your git server ([Redirectingā¦ - Bitrise Docs](http://devcenter.bitrise.io/webhooks/)), and if you use our GitHub/Bitbucket/GitLab integration this is automatically prepared for you.
> [@Shashikant](#):
>
> But what if developer directly want to create āReleaseā build directly from his machine
One solution can be to have a workflow for the Release, and trigger that automatically if you merge into e.g. `master`, or you (or your dev) pushes a git tag. See: [Using the Trigger Map to trigger builds - Bitrise Docs](http://devcenter.bitrise.io/webhooks/trigger-map/) - specifically [Using the Trigger Map to trigger builds - Bitrise Docs](http://devcenter.bitrise.io/webhooks/trigger-map/#a-very-simple-two-workflow-cicd-setup)
> [@Shashikant](#):
>
> What he know is the command like ābitrise run releaseā and it will upload the build on iTunesConnect directly.
That definitely should work locally too, given that the dev has the required secrets (iTunesConnect usd+psw) set locally in Secrets. Pretty much all of the steps work locally, 3rd party service integrations definitely do, the exception is the **Deploy to [Bitrise.io](http://Bitrise.io)** step (and the Cache steps) which require [bitrise.io](http://bitrise.io) to be available, otherwise the step doesnāt know where to push the artifacts (as artifacts on [bitrise.io](http://bitrise.io) are tied to the build it generated).
> [@Shashikant](#):
>
> or wait for pull request to be merged and approved.
You definitely should wait for that before publishing into a store š
If you just want to publish to [bitrise.io](http://bitrise.io) for the PR then you can simply include the **Deploy to [Bitrise.io](http://Bitrise.io)** step in the PR check buildās workflow.
> [@Shashikant](#):
>
> I know it is breaking some of the standards but It was just my thoughts.
Sure, and thank you for the feedback, we really appreciate it & it helps a lot! š We just have to see/understand what the exact use case is, so that we can talk about it with the team and come up with an appropriate solution š