Burak Yigit Kaya

@kamilogorek looks like this needs to be transferred to [getsentry/sentry-go](https://github.com/getsentry/sentry-go) but I cannot do it.

We try up to 3 times: https://github.com/getsentry/craft/blob/03fda08404939fb2a88c5059e1e5634689ea1cf1/src/targets/github.ts#L389 We can probably increase it and also add some delay?

This should be done in the project config itself as the order is deterministic already?

I strongly disagree with this approach, at least without keeping the old config. A better way forward then would be to adopt a dictionary of targets with clear relationships defined...

@iker-barriocanal >How would you deal with half releases? If a target fails, we want to stop the release and don't continue with other targets. You obviously won't execute any dependents...

> but if one of them fails we don't want to run the others to prevent releasing to a subset of places. Does it mean we'd have to add dependants...

@iker-barriocanal not every target. The current way, the ordered-list definition does what you say and we will keep that way of defining targets for backwards compatibility. What I'm proposing is...

This became quite feasible after #285. We can combine this with https://github.com/npm/node-semver and achieve what @jan-auer suggested. Would this still be cool?

Looks like we can use the [check suites API](https://developer.github.com/v3/checks/suites/#list-check-suites-for-a-git-reference) to get a list of pending suites even if the check runs never start/report in. We should only fail with a...

This should never happen if you are doing the releases via `getsentry/publish`. It can only happen locally and the solution to that is probably changing this line: https://github.com/getsentry/craft/blob/6d523c5883eb0cadfa6ab33220d966e2ffd5fca9/src/utils/git.ts#L46 To point...