You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 4, 2024. It is now read-only.
We currently have a monorepo setup where code for various components in our application lies. This makes it easier for making changes across multiple services when implementing features.
One problem we had was that this creates a lot of builds, so we opted to use circleci's dynamic configuration. We generate the configuration automatically based on the changes that are being done in the pull request. I am parsing the commit bors-ng creates to trace back to the pull requests in question.
The problem I encountered with bors-ng is it relies on static status entries in the bors.toml configuration. Since the jobs are dynamic, some statuses might not show up on a commit depending on what was changed in the pull request. What I did to work around this is create a dummy job that depends on all of the conditional jobs, and tell bors-ng to check for the status of that job. This solves my problem when all of the dynamic jobs are green, but when a job fails bors-ng times out, since the dummy job never runs.
Potential solution would be to have a fail_status configuration in bors.toml. This would only check if the github status failed, but doesn't require it to be present to merge.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
We currently have a monorepo setup where code for various components in our application lies. This makes it easier for making changes across multiple services when implementing features.
One problem we had was that this creates a lot of builds, so we opted to use circleci's dynamic configuration. We generate the configuration automatically based on the changes that are being done in the pull request. I am parsing the commit bors-ng creates to trace back to the pull requests in question.
The problem I encountered with bors-ng is it relies on static status entries in the
bors.toml
configuration. Since the jobs are dynamic, some statuses might not show up on a commit depending on what was changed in the pull request. What I did to work around this is create a dummy job that depends on all of the conditional jobs, and tell bors-ng to check for the status of that job. This solves my problem when all of the dynamic jobs are green, but when a job fails bors-ng times out, since the dummy job never runs.Potential solution would be to have a
fail_status
configuration inbors.toml
. This would only check if the github status failed, but doesn't require it to be present to merge.The text was updated successfully, but these errors were encountered: