I didn’t see this feature is exits on Buildkite but i wanna be sure about that. We would like to communicate two different private repository in same organization.
We have SDK (as npm package) and API project. When we deploy new version for SDK project we need to update SDK version on API project. On this point, we thought when SDK’s buildkite pipeline process is done, we are gonna create new step for buildkite.
And, it’s gonna send a trigger event to API project’s buildkite pipeline and when trigger event comes to API project, it will start to its own pipeline process.
Do we have this feature on Buildkite ? If not, is is possible to do that with alternative way ?
A trigger could work, but may or may not be the right thing to do. You’ll need to update the source code of your API with the new SDK version, which involves committing back to the repository. You might want to have a step at the end of your SDK pipeline that checks out your API repo, edits the version of the SDK it depends on, and then pushes that as a new pull request on the API repo. Then, your API pipeline would automatically run. That way, you ensure the tests all pass, and you also have the opportunity to easily make any manual fixes that might be necessary if they don’t.
Alternatively, at the end of your SDK pipeline run, you may want to trigger a separate pipeline on your API repository (you can have any number of pipelines on a repository) that submits that PR. You can send the new version of the SDK in the trigger itself using either meta-data or an environment variable. This new pipeline would only create the new PR. Then, your “normal” API pipeline would kick off as described above. The nice thing about this arrangement is that the logic for updating the API repository would live in the API repository, and not in the SDK repository.
A thing to improve on that even further would be to have a way for your API repository to “know” that it depends on the SDK, which further consolidates all your API logic in the API repository (as described above, the SDK repository would need to know everything that depends on it, in order to know what to update / trigger). This would require additional infrastructure apart from what Buildkite provides natively, however. We had something like this at a previous workplace of mine, and it was really nice. But, that requires a lot of extra work.