Passing off for consideration.

@dgarrett: Can you explain a little more what the request of this feature is exactly? I know payload tryjobs run like cros tryjob ... . I'm assuming this is so we can remove the --version and --channel flags from tryjobs. But I guess we probably want to have patching capability (-g) so we can at least be able to patch the chromite. This is the only way I can sent paygen tests without trying to break all the canaries :/ (which I have done numerous times). It is not really easy to test paygens without this. Actually even with this I have to send a CL that also disables a lot of other things. If we move this out of tryjobs, then either we have to add -g capability, or completely forget ignore that.

But on a general note, what is the exact purpose of payload tryjobs? Is it that if for some reason like infra problem or lack of DUT some payloads could not be created, this way TMPs can create them at a later time?


A while ago I opened a feature request crbug.com/793024. Although, I didn't understand fully the mechanisms are paygens at that time, my intention was to be able to patch the source for update engine, paygen, etc and run the paygen tests without going through canary first. I'm not sure if it is a good idea or not and would like to know your opinion on it too.

payloads tryjobs are intended to let TPMs retry payload generation and testing if they want to use a release build that passed all tests, but failed during Paygen.

Originally, both payload generation and payload testing were pretty flaky, so both would commonly need to be retried.

I believe that's only true for the tests now, which can be more efficiently rescheduled by going straight to the lab, though I don't think the tools for that are friendly enough yet.

I filed this because of frustration with the goofy payloads tryjob argument handling, but really I'd like to rethink how we run paygen in general. Not that I have a good plan in mind.

It's probably reasonable to either "WontFix" or hand over to jclinton@ for fitting it into this CI 2020 roadmap.

@jclinton: As recommended in #6, can you take a look at some of these requirements and see if it can be fit into our future roadmaps? We probably want to make payload generation and testing more convenient both for production and development. 

I will evaluate.