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
It would be nice to use multiple build jobs (remember our SUBDAG feature) in case of bigger pull requests. However, for the regular pull request, this is not necessary and creates a lot of overhead. We should try to do the following:
the regular, automatic travis job investigates the DAG of packages that need to be build.
if the DAG is small, go on with building it
if the DAG is big, and can be split up into several disconnected subdags, trigger a new travis build (see API) with an appropriate build matrix set (e.g. defining n SUBDAG jobs). Then stop the current job.
This way, we get parallelism for connected subdags in case of large builds, and don't have additional overhead in case of small builds. If this works, it is a much superior solution compared to the feedstock approach, because we are able to automatically deal with the dependencies between packages without the downside that all builds run in a single job.
@bioconda/core, what do you think?
The text was updated successfully, but these errors were encountered:
It would be nice to use multiple build jobs (remember our SUBDAG feature) in case of bigger pull requests. However, for the regular pull request, this is not necessary and creates a lot of overhead. We should try to do the following:
This way, we get parallelism for connected subdags in case of large builds, and don't have additional overhead in case of small builds. If this works, it is a much superior solution compared to the feedstock approach, because we are able to automatically deal with the dependencies between packages without the downside that all builds run in a single job.
@bioconda/core, what do you think?
The text was updated successfully, but these errors were encountered: