Add pipeline-lib branch update action

[brianjmurrell]

Signed-off-by: Brian J. Murrell brian.murrell@intel.com

[daosbuild1]

Test stage provisionNodes with slurm Leap15 completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/pipeline-lib/job/PR-156/18/display/redirect

[daosbuild1]

Test stage provisionNodes with slurm EL7 completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/pipeline-lib/job/PR-156/19/display/redirect

[daosbuild1]

Test stage provisionNodes with release/0.9 Repo completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/pipeline-lib/job/PR-156/19/display/redirect

[daosbuild1]

Test stage provisionNodes with master Repo completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/pipeline-lib/job/PR-156/19/display/redirect

[daosbuild1]

Test stage provisionNodes with master Repo completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/pipeline-lib/job/PR-156/21/display/redirect

[daosbuild1]

Test stage provisionNodes with release/0.9 Repo completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/pipeline-lib/job/PR-156/21/display/redirect

[daosbuild1]

Test stage provisionNodes with slurm Leap15 completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/pipeline-lib/job/PR-156/23/display/redirect

[daosbuild1]

Test stage provisionNodes with master Repo completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/pipeline-lib/job/PR-156/23/display/redirect

[daosbuild1]

Test stage provisionNodes with slurm EL7 completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/pipeline-lib/job/PR-156/23/display/redirect

[daosbuild1]

Test stage provisionNodes with release/0.9 Repo completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/pipeline-lib/job/PR-156/23/display/redirect

[daosbuild1]

Test stage provisionNodes with slurm EL7 completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/pipeline-lib/job/PR-156/26/display/redirect

[daosbuild1]

Test stage provisionNodes with slurm Leap15 completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/pipeline-lib/job/PR-156/26/display/redirect

[daosbuild1]

Test stage provisionNodes with release/0.9 Repo completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/pipeline-lib/job/PR-156/26/display/redirect

[daosbuild1]

Test stage provisionNodes with master Repo completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/pipeline-lib/job/PR-156/26/display/redirect

[daosbuild1]

Test stage provisionNodes with master Repo completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/pipeline-lib/job/PR-156/28/display/redirect

[daosbuild1]

Test stage provisionNodes with slurm EL7 completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/pipeline-lib/job/PR-156/28/display/redirect

[daosbuild1]

Test stage provisionNodes with slurm Leap15 completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/pipeline-lib/job/PR-156/28/display/redirect

[daosbuild1]

Test stage provisionNodes with release/0.9 Repo completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/pipeline-lib/job/PR-156/28/display/redirect

[JohnMalmberg]

I think we need to handle the intentionally aborted job better before landing this to cut down on the e-mail noise.

It may help to add a sleep stage before starting any stages that do a notify.

Also test the case were we are testing a change to the trusted-pipeline-lib.

[brianjmurrell]

I think we need to handle the intentionally aborted job better before landing this to cut down on the e-mail noise.

The only people who see noise are people who are subscribed to the ticket, such as reviewers. So it's not even noisy until review time, not unlike the updates that you get from every other ticket you are subscribed to. You can unsubscribe to a ticket if it's too noisy and you will only get notified again when you are asked for re-review.

It may help to add a sleep stage before starting any stages that do a notify.

Maybe. I think we can experiment with that as we use it in our *pipeline-lib repos before we implement in daos.

Also test the case were we are testing a change to the trusted-pipeline-lib.

daos-stack/trusted-pipeline-lib#3

[JohnMalmberg]

I meant testing a pipeline-lib PR that is also testing a change to trusted-pipeline-lib so we have to specify something like for example: @Library(value="trusted-pipeline-lib@master") _

This would need to be changed to:
`@Library(value=["pipeline-lib@bmurrell/pipeline-lib-branch-action","trusted-pipeline-lib@master"])

[brianjmurrell]

I meant testing a pipeline-lib PR that is also testing a change to trusted-pipeline-lib so we have to specify something like for example: @Library(value="trusted-pipeline-lib@master") _

This would need to be changed to:
`@Library(value=["pipeline-lib@bmurrell/pipeline-lib-branch-action","trusted-pipeline-lib@master"])

You probably meant something other than master here for trusted-pipeline-lib, but I think I see your point.

At this point, I'd be inclined to not let the perfect be the enemy of the good as this is really just an experiment to see if this can be an acceptable workflow. If we decide it's workable, we can extend it to cover the corner cases. But I'd rather not spend the time trying to make it perfect before we decide we like it or not.

As for the failed test notifications that happen when the action pushes a patch, I think that's really quite a non-issue. That only ever happens once for a PR on the very first commit. At that point the only person who will get those notifications is the owner as it's unlikely that there will be any reviewers added when the PR is created. But even subsequent pushes of patches don't create those notifications, as the change is already made by that point and the action is a NOOP.

The ultimate solution for this is the QuietPeriod, and it looks like a PR for that to be working in Multibranch Pipelines is being resurrected so hopefully we will have that soon-ish.

In the meanwhile we can experiment with sleeps (how long, etc.) as we push patches to pipeline-lib and evaluate the usefulness of the action.