general: seems to assume some familiarity
with Jenkins. I personally lack that, so I'm interpreting 'pipeline'
in a fairly general sense that appears to agree with the bold build
script (pipeline), at [1]
before/after: not obvious why before.3
is an issue. saying it's _easier_ to build a UI showing the steps,
sure. saying it's _impossible_ w/o OSLC seems like an overstatement.
before/after: it sounds from the slides
like _when it is the case that before.1/2 use non-standard APIs_ that a
separate Jenkins plugin is needed, which is a barrier for the implementations
- or are they already assumed to all know and love the Jenkins plugin API?
Jenkins scenario [1]:
J1: "configured to be a "friend"
to two OSLC servers" ... what is this 'friend' term, a Jenkins term
of art? Not sure what it would mean. I know what it means to
JTS, but that's not the context here.
J2: "Jenkins inserts "${BUILD_TAG}"
"... is this syntax something you foresee Automation defining, or
an ignorable (wrt Automation) implementation choice? To first order,
these sorts of IDs flowing where the/some client is "just supposed
to know what to do with them" screams out "then use a URI instead
of a proprietary ID!" to me.
J3: "Simple, three steps "
... well they're not #d, but >> 3 to my eyes. 3 steps in the
example pipeline, but >>3 in the scenario.
J4: "Deployment plan might need
to be tightly-coupled to Jenkins. " Well the implementation
would be, perhaps. At the interface level, it's the name/value pairs
that form the interface to each Plan (which apparently Jenkins calls a
pipeline step), in the sense of "what part of a Plan's interface is
not standardised by Automation already". Is this leading to
standardization of some set of Plans and/or parameter names, in your mind?
J5: "User might need to tie parameters
together manually. - This scenario doesn't actually encounter this problem.
" To me, that's exactly what's going on here, so this makes
me think I'm reading it differently than you intended. In the slides,
how does the user know that the env on 13 is the same one from 8? Aside
from the potentially coincidental use of a common label in a UI, knowing
that they are "wanting" to re-use a single concept seems like
exactly a bit of knowledge filled in by the user.
slides:
10: "standard for artifact
repositories" ... not sure how it's positioned, but certainly it is
true that OSLC Asset Mgmt [2] exists and has been used as the API for at
least one artifact repo (Rational Asset Mgr). I could also say that
any API with a collection in it (nearly all of them) fit the words "artifact
repo" though, so perhaps there is some implied meaning involved that
I'm not grokking. LDP is another [3].
[1] https://wiki.oasis-open.org/oslc-automation/UseCasesAndRequirements/DeployingBuildArtifactsContinuousIntegration
[2] open-services.net ailing at this
hour - google it.
[3] http://www.w3.org/TR/ldp/
Best Regards, John
Voice US 845-435-9470 BluePages
Cloud and Smarter Infrastructure OSLC
Lead
