This required the concepts of stateful and stateless channels to be introduced,
which will have different persistence guarantees.
The two types of channels will help the eventbus determine where it can be cheap
and efficient, and where it should involve more expensive storage. When I think
of an eventbus interface implemented on top of Redis, I would use BLPOP lists
for stateful channels and pub/sub for stateless channels.
The entities represented I believe are the bare minimum number of services
necessary to make things roughly work. The idea being that everything
effectively orients around the eventbus, and "extensibility" means tuning into
or publishing events rather than in-memory anything.
Fixes#20
The originally idea here was that I would use the tsconfig.base.json to extend
in various submodules. As it stands right now, the submodules having their own
configuration doesn't quite make sense
In the context of the cache {} block, we don't want to use `from` to copy the
cache directives from another stage entirely, rather we want to "use" the named
cached entry.
I think it makes sense to allow caches to be pulled individually. Imagining a
case where a compilation stage might create multiple platform specific
directories or binaries. In such cases, a Windows test-specific stage would only
want to grab the cached entries for Windows, etc.
ANTLR4 will generate a `notify` method which causes a compile time error:
Otto.java:982: error: notify() in StageStatementsContext cannot override notify() in Object
public NotifyContext notify() {
^
overridden method is final
Otto.java:1831: error: notify() in Otto cannot override notify() in Object
public final NotifyContext notify() throws RecognitionException {
^
overridden method is final
2 errors
While we're not focusing on Java right now, ensuring some compilation works
properly is not a bad thing
There's still something off, but I'm checkpointing this here to make sure I
don't make any more changes 😸
The problem with the grammar as is, is that it fails to parse the stage after
the each macro in matrix.otto
Still exploring the syntax here a bit. The expectation is that blah() syntax
would actually be invoking macros which would simple expand out at parse/compile
time.
In this example, the `each` macro would create four different stage blocks.
Inside of those macro blocks, the keyword `it` is introduced to represent the
item which is intended to be substituted.
Each of those stage blocks have a name created using the`concat` macro.
None of the other blocks have parenthesis and take arguments the way the
stage(name) does. To make all blocks behave a bit more in line with one another,
this commit changes the behavior of naming stages to look more like a
generalized block settings.
This presages some macro work that's coming in the following commits.
This syntax makes it more clear the conditions not only that a stage can be
entered , but what conditions must be met in order for the stage to
exit/complete.
There's a slight nuance, which I am not certain at the moment is important with
'when' in the declarative Jenkins Pipeline syntax as it relates to 'enter' here.
The 'when' directive can be used to prevent a stage from being executed in a
flow, i.e. skipped. An "enter" however could mean "wait for this criteria to be met"
which might be confusing to a user, but I think this initial simplicity is worth
the experiment.
The "exit" is obviously a bit easier to understand, but where some nuance will
come later on is how we might determine/model what exit criteria should hold
onto cluster resources, versus a simple "listener" which requires no 'runtime'
R Tyler Croy
dependabot[bot]