Need a "retest on LAVA" button on android-build

[Zach Pfeffer]

A recent failure: https://android-build.linaro.org/jenkins/job/linaro-android_staging-panda/49/parsed_console/? showed that android-build.l.o submitted a job to v-l-o and it failed to connect. It would be good to have a re-test button on the build page: https://android-build.linaro.org/builds/~linaro-android/staging-panda/#build=49 to handle this case (auto retest on failure could be a next step).

[Yongqin Liu (liuyq0307)]

And there is another thing, it should first submit the job using, the job has not been submitted to v-l-o.
So may be it's better to provide an interface on v-l-o to submit job for this case.

[Fathi Boudra (fboudra)]

Unassigned Yongqin Liu. Validation Team need to estimate the work and plan as appropriate.
AFAICS, it's changing the UI front end to re-submit a job using the LAVA interface provided by Validation Team.

[Yongqin Liu (liuyq0307)]

I have done some parts. see branch. lp:~liuyq0307/linaro-android-frontend/fix-878832
It's mainly related to the display on the android page. please see the attachment for reference.

[Paul Larson (pwlars)]

another possibility here is that it would be useful to have a "retest" button in the scheduler for any test job. What it would do, is to resubmit the exact same job json again, and return the new job number. This would not *replace* the previous job, just do it again basically. It would be simple enough to also give it a "resubmit" api that does the same thing when given the job number, and we could make use of that here. There's a blueprint in for this right now.

[Michael Hudson-Doyle (mwhudson)]

On Fri, 28 Oct 2011 18:01:20 -0000, Paul Larson <email address hidden> wrote:
> another possibility here is that it would be useful to have a "retest"
> button in the scheduler for any test job. What it would do, is to
> resubmit the exact same job json again, and return the new job number.
> This would not *replace* the previous job, just do it again basically.
> It would be simple enough to also give it a "resubmit" api that does the
> same thing when given the job number, and we could make use of that
> here. There's a blueprint in for this right now.

The problem with a retest button in the scheduler is that android-build
records the ID of the originally submitted job, so even if the job is
run again, the android-build build page will still show the original
results. I imagine this is not what is wanted.

However, James and I had a conversation about this a while ago and came
up with this idea: allow scheduler jobs to be referenced by job_name, at a
URL along the lines of:

    $lava-server/scheduler/+job-by-name/$JOB_NAME

The immediate objection to this idea is that $JOB_NAME is not
necessarily unique -- but we can turn that into a feature by having the
above URL return the *most recently submitted* job with that name --
which means that using a retest button in the scheduler will do the
right thing.

Given that the job name is now recorded in the database (as
'description', perhaps slightly confusingly) this should be easy enough
to implement.

Cheers,
mwh

[Paul Larson (pwlars)]

That's probably ok, as long as we are pretty sure that we wouldn't have an *unrelated* job with the same job name. That's unlikely to happen here, not sure about other cases. Does this help them pull in the results to the build page though? or just link to them?

I was thinking if they had a button they clicked to resubmit the job, it would just resubmit the original job and get back a new job id that could be used the same way as before to reference the results. This could be appended to the existing results on the build page, or replace it, which ever their preference.

[Michael Hudson-Doyle (mwhudson)]

On Mon, 31 Oct 2011 13:56:58 -0000, Paul Larson <email address hidden> wrote:
> That's probably ok, as long as we are pretty sure that we wouldn't have
> an *unrelated* job with the same job name. That's unlikely to happen
> here, not sure about other cases.

Ah yes this is what happens when I write emails when super tired on
planes: I forget things.

I regard the issue of multiple jobs with the same ID to fall into the
"if you break it you get to keep both pieces" sort of thing.

> Does this help them pull in the results to the build page though? or
> just link to them?

In the implementation I had in mind it would do both. Instead of
hitting

  $scheduler/$job_id/json

to get the bundle link as it does today, the page would hit something
like:

  $scheduler/+by-job-name/$job_name/json

which would return a link to the results of the most recent job with
that name.

> I was thinking if they had a button they clicked to resubmit the job, it
> would just resubmit the original job and get back a new job id that
> could be used the same way as before to reference the results. This
> could be appended to the existing results on the build page, or replace
> it, which ever their preference.

Yeah, that could work. I guess I tend to regard the build artifacts
as immutable -- although that's not strictly speaking the case.

Cheers,
mwh

[Alexander Sack (asac)]

we need this feature to enforce LAVA success as part of our release process. Please come back with the most minimal intrusive approach you can think of so we can make it happen during the .03 cycle.

[Paul Sokolovsky (pfalcon)]

It's unclear why this gets "Critical" for Linaro Infrastructure - it doesn't represent existing feature which broke and needs urgent fix. It doesn't even represent anything which Infrastructure team can work on - it depends on LAVA features. Adjusting correspondingly.

[Milosz Wasilewski (mwasilew)]

Not needed in Android anymore.

[Fathi Boudra (fboudra)]

Superseded provided by the feature in LAVA to re-submit job (job actions).