[petsc-dev] Pause-for-approval Pipelines?

Barry Smith bsmith at petsc.dev
Thu Aug 27 18:31:52 CDT 2020


  Can't see where the test is that decides if a docs pipeline is needed and launched but presumably it is there somewhere in all the syntax.

https://gitlab.com/gitlab-org/gitlab/-/blob/86bc0e2ed2fa32198a562e09bf36dab5821ece22/scripts/trigger-build <https://gitlab.com/gitlab-org/gitlab/-/blob/86bc0e2ed2fa32198a562e09bf36dab5821ece22/scripts/trigger-build>

If we could figure this out then our pipeline could do docs or source testing (or both) depending on the changes without user intervention. Heck maybe even run only the tests affected by the MR changes and not all the rest speeding things way up. 

-------------

If Hong pushes a TS change why run any tests below TS? Or Alp a TAO change? 

Maybe we can test only the relevant part without understanding this!

 Just a git diff to figure out the directories changed and extra argument to the test harness. Or better put it in the test harness.

 make -f gmakefile.test branchchanges

could shave on average 50 percent of the testing time even with a crude cautious limit on unneeded tests.











> On Aug 27, 2020, at 6:04 PM, Scott Kruger <kruger at txcorp.com> wrote:
> 
> 
>>> What's wrong with using the API to release the paused job instead of using it to start a fresh pipeline?
>>   Generally I like to pass the Pipeline before making a PR. So the test on creating a new MR is annoying. Yes after the initial MR I might be able to release the paused job in lieu of starting pipelines fresh. It would be nice to send some pushes that don't trigger a pipeline start at all because I know I don't need one. Maybe that is possible, I'll need to investigate.
>> 
> 
> I agree with this, but this would require keying off of labels rather than just MR.  
> The new `rules:` keyword is supposed to be more flexible, but from the docs,
> I can't tell that changing a label can launch an pipeline:
> 
> https://docs.gitlab.com/ee/ci/yaml/#workflowrules <https://docs.gitlab.com/ee/ci/yaml/#workflowrules>
> 
> They do show examples of ignore WIP, but it looks like it applies to commits?
> 
> But going back to the original point, gitlab supports documentation only pipelines:
> https://docs.gitlab.com/ee/development/pipelines.html <https://docs.gitlab.com/ee/development/pipelines.html>
> 
> So, in the end, I can't tell if gitlab can do what we want or not.
> 
> 
> Scott
> 
> 
> 
> -- 
> Tech-X Corporation               kruger at txcorp.com <mailto:kruger at txcorp.com>
> 5621 Arapahoe Ave, Suite A       Phone: (720) 974-1841
> Boulder, CO 80303                Fax:   (303) 448-7756

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20200827/cda2a769/attachment-0001.html>


More information about the petsc-dev mailing list