OSLC Automation - Automation Plan semantics

#1

Hi,

I am implementing an OSLC Automation provider and there is something I am not sure about when it comes to Automation Plans.

Imagine an Automation provider for a bunch of testing tools. It should allow clients to submit a program to be analyzed by one of the analysers, and then allow them to get the result.
Looking at the example provided in the OSLC Automation Primer (even though the example is a build tool), I am unsure what the program to analyze would map to. The example looks like there is an Automation Plan specific to one program to be built. Now the OSLC Automation specification only requires a GET capability for Automation Plans so it seems like Automation Plans are meant to be read-only for clients. How would the Automation Provider build other programs if the POST capability for Automation Plans isnt required?

I see two options for my analysis example:

  1. The provider has an Automation Plan for each analysis tool, and the Automation Plans only have a GET capability. The program to analyze is one of the input parameters specified in an Automation Request.
  2. The program to analyze is a part of the Automation Plan. The user creates an Automation Plan specifically for each program.

Is this an implementation choice or is one of the options preferred by the specification?
I’d be very grateful for some thoughts or suggestions!

Thanks & Best regards,
Ondrej Vasicek

#2

Hello Ondrej,

I think the idea behind not requiring POST on Automation Plans is that they can be created/defined in any way possible (eg I can imagine you parsing a .gitlab-ci.yml file from a repo and creating an Automation Plan per build stage). It does not mean the Automation Plans are supposed to be static.

I think both of your options are valid. If you think that analysis will be provided as a service, option 1 sounds good to me. If you extract (and live-update) the Automation Plan for analysis from Gitlab CI file (e.g. by defining a custom analysis stage), I would go for option 2.

I have also asked a colleague with OSLC Automation hands-on experience (I have none, to be clear) to look at your question and provide his opinion too.

Cheers,
Andrew

#3

Hello Andrew,

Thanks! Seeing the automation provider as a testing service or as a part of a Gitlab CI stage is interesting. I have already implemented the first option for another testing service application, and my current project seems to be more similar to the Gitlab CI scenario.

I’ll be on the lookout for your colleagues answer in case he has any more thoughts about this.

Thanks & Have a great day!
Ondrej

1 Like