Minor copy edits

This commit is contained in:
R Tyler Croy 2020-11-06 13:37:02 -08:00
parent 527f94e96a
commit ce284ffb0b
No known key found for this signature in database
GPG Key ID: E5C92681BEF6CEA2
1 changed files with 14 additions and 14 deletions

View File

@ -48,17 +48,16 @@ For Otto however, the goal is not to create a Jenkins Pipeline knock-off. In
this post I wanted to share some sketches of what I think Otto Pipelines should this post I wanted to share some sketches of what I think Otto Pipelines should
look like and why. For starters, the README [has an incomplete look like and why. For starters, the README [has an incomplete
list](https://github.com/rtyler/otto/tree/3c2daa412ab091d827040c56f891ad0fdcd7cd2c#modeling-continuous-delivery) list](https://github.com/rtyler/otto/tree/3c2daa412ab091d827040c56f891ad0fdcd7cd2c#modeling-continuous-delivery)
which covers some high-level goals I have for modeling continuous delivery, covering some high-level goals that I have for modeling continuous delivery. The [examples/
which is worth a look. The [examples/
directory](https://github.com/rtyler/otto/tree/3c2daa412ab091d827040c56f891ad0fdcd7cd2c/examples) directory](https://github.com/rtyler/otto/tree/3c2daa412ab091d827040c56f891ad0fdcd7cd2c/examples)
also has a few sample `.otto` files which I will use for reference throughout also has a few sample `.otto` files which I will use for reference throughout
this post. this post.
It may also be worth reading My previous post describing [step It may also be worth reading my previous post describing [Step
libraries](/2020/10/18/otto-steps.html) if you haven't already, since they play Libraries](/2020/10/18/otto-steps.html) if you haven't already, since they play
an integral part in making this syntax "go." an integral part in making this syntax "go."
With the pre-requisites out of the way, let's walk through some syntax. With the pre-requisites out of the way, let's walk through some syntax!
## Defining the available tools ## Defining the available tools
@ -140,7 +139,7 @@ to one-off `Dockerfile`s which just take an upstream image and add one or two
dependencies. dependencies.
With a capabilities-oriented model, the pipeline orchestration layer is no With a capabilities-oriented model, the pipeline orchestration layer is no
longer looking for machines labeled "linux-pythoN" or and then hoping one is longer looking for machines labeled "linux-python" or and then hoping one is
available. Instead the orchestrator can be smarter and find any available available. Instead the orchestrator can be smarter and find any available
capacity to meet the capabilities request. I believe this approach can improve capacity to meet the capabilities request. I believe this approach can improve
on overall system performance and scheduling. An idea which I have floating on overall system performance and scheduling. An idea which I have floating
@ -170,8 +169,8 @@ system is overuse of remote resources by pipelines. [This is not a niche
problem](https://twitter.com/technosophos/status/1324037674588463105), but problem](https://twitter.com/technosophos/status/1324037674588463105), but
rather something that affects practically everybody. Some will say "you should rather something that affects practically everybody. Some will say "you should
be caching and proxying all your remote resources!" which is simply not a be caching and proxying all your remote resources!" which is simply not a
practical solution for the vast majority of the users in the ecosystem who are practical solution for the vast majority of the users in the ecosystem. Many at
not at large enough organizations to deploy such caching proxies. users won't be at organizations large enough to deploy such caching proxies.
```groovy ```groovy
stage { stage {
@ -210,11 +209,12 @@ artifacts is relatively quick, which I don't believe will be a major challenge.
## Composition and Re-use ## Composition and Re-use
Inevitably developers try to abstract common functionality and behaviors into Inevitably developers try to abstract common functionality and behaviors into
re-usable components. Step libraries can provide one flavor of this re-usable components. Step Libraries can provide one flavor of this
re-usability, but I don't believe that it is sufficient. I once joked about re-usability, but I don't believe that it is sufficient. The ubiqitous adoption
[the five stages of YAML](/2018/08/15/five-stages-of-yaml.html) wherein of YAML by newer CI/CD tools lead me to joke about [the five stages of
developers end up turning a declarative syntax into templates and then just YAML](/2018/08/15/five-stages-of-yaml.html) wherein developers end up turning a
another turing-complete language. declarative syntax into templates and then into just another turing-complete
language.
In Jenkins we have seen numerous tools for templatizing jobs, pipelines, or In Jenkins we have seen numerous tools for templatizing jobs, pipelines, or
other aspects of Jenkins configuration. Suffice it to say, there is a need to other aspects of Jenkins configuration. Suffice it to say, there is a need to
@ -237,7 +237,7 @@ stage {
In the above example, `from` instructs the pipeline to re-use the contents of In the above example, `from` instructs the pipeline to re-use the contents of
the runtime block from the `Build` stage. My current thinking is that this the runtime block from the `Build` stage. My current thinking is that this
simple use of `from` allows for pipeline-internal re-use of pieces without the simple use of `from` allows for pipeline-internal re-use of pieces without the
need for setting variables or turning this into a scripting language. need to set variables or turn this into a scripting language.
That said, re-usability within the pipeline isn't where the main interest in That said, re-usability within the pipeline isn't where the main interest in
"templates" lies. "templates" lies.