Currently generation of yum metadata is delayed for 60 seconds after an rpm has been deployed. The reason for this is that the yum metadata format consists of a handful of potentially very large XML files. These can be very expensive to rebuild, and so we need to avoid overwhelming Nexus Repo with many tasks to rebuild metadata in the event of rapid rpm deployments.
This metadata rebuild behavior causes a problem for CI builds that depend on deployed rpm's to be available immediately after the job that builds and deploys them finishes. Subsequent jobs very often fail because the newly deployed rpm file is not immediately available through the hosted repository. Currently the only workaround is to introduce a delay period into the CI job after deployment, but this can never work with complete effectiveness, because it isn't always possible to predict when the rpm metadata rebuild task will start, or how long it will take to finish.
To handle this use case, I propose a to add a way to make a CI client block until any pending yum metadata updates have completed.
One way to do that would be to add an option to yum deployment in component REST API. This flag would tell the POST request to not return until the yum metadata rebuild has been completed. In this way, CI jobs could be built which reliably deploy and consume rpm files.
Another possibility would be a new REST API that will return immediately if there are no pending yum metadata updates for the target repository, or if there are pending updates, will block until they complete.