Please don't merge this at this moment, it depends on #471 (the commit is included in this PR), I'll rebase this PR once #471 is merged.

Hey qwan, can you resolve the conflicts? Probably because we merged the PR about the handler, so you need to rebase on master.

PR is rebased and ready for review.

I think for async rebuilds, this is not list of leaf container images. If I understand it right, it is list of images sharing parent-child relationship which are then rebuild by Freshmaker in the right order. I'm not sure how to formulate the fact that you can specify ["A", "C"] and it can rebuild A -> B -> C.

Anyway, I think description of this field should be explained in very good way, because people will ask meaning of this field and it's easier to show them docs then explaining it again and again :).

I think the way how to get dependent_event should be moved to new helper function (similar to _validate_rebuild_request) and it should be used also in BuildAPI.post. That should also ensure that BuildAPI.post cannot reuse FreshmakerAsyncManualBuildEvent. The errata_id handling in BuildApi.post can stay just in BuildApi.post. I hope it makes sense... :)

Updated:
1. Added checking of event type in BuildAPI.post, it can't be an async build event.
2. Moved the validation of freshmaker_event_id to _validate_rebuild_request, but still keep the checking of event type in BuildAPI.post and AsyncBuildAPI.post.
3. Updated docstring of container_images in AsyncBuildAPI.post, however it seems to be not precise enough, @gnaponie do you have any suggestion for me on this?

It will be possible to request the rebuild of images completed unrelated to each others. But yes, what Jan said is correct: if we have A -> B -> C and the user requests to rebuild A and C, then also B will have to be rebuilt.
More info are in the design document, and probably we should add more details in here as Jan suggested.

We finally have the CI working again in here. And it seems like it's failing for this PR. Could you please check it?
I've tried to run locally the tests and they pass for me. But can we check why it fails in the CI?

1. Updated docstring of container_images in AsyncBuildAPI.post, however it seems to be not precise enough, @gnaponie do you have any suggestion for me on this?

Yeah. What about something like this:
A list of images to rebuild. They might be sharing a parent-child relationship which are then rebuilt by Freshmaker in the right order. For example, if images A is parent image of B, which is parent image of C, and container_images is [A, B, C], Freshmaker will make sure to rebuild all three images, in the correct order. It is however possible also to rebuild images completely unrelated to each other.
This is a mandatory field.

I would maybe specify the default value, which should be (from the design doc): the default value will be pulled from the previous buildContainer task.

optional: this code is shared with the normal rebuild. Maybe it can be mapped to a utils function.

@gnaponie sorry, I missed your last two comments before pushing the amended PR, could you please comment that again? I'm not sure about the exact lines you mentioned.
Regarding the CI, seems it's something wrong with setting the FRESHMAKER_TESTING_ENV in tox, though it's weird that I ran tox locally for several times and all tests passed, will figure it out.

A new commit is added to fix the tests (broken due to new version (>=0.5) of flask_login).

Thank you for fixing the tests!!

optional: this code is shared with the normal rebuild. Maybe it can be mapped to a utils function.

I would maybe specify the default value, which should be (from the design doc): the default value will be pulled from the previous buildContainer task.

@gnaponie sorry, I missed your last two comments before pushing the amended PR, could you please comment that again? I'm not sure about the exact lines you mentioned.

I've reposted them :)

@gnaponie PR is updated to address the comments.

It looks great! Thank you @qwan :)

Commit 2ffdf98b fixes this pull-request