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'
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.
This is still just a sketch of what's in my brain. The internal representation
is likely going to have to evolve a lot more once the parser gets further along
This of course comes with no actual implementation, but it at least provides a
grammar to start with. There's likely some cleanup in the rules and edge cases
that are missing, but this is a start.
This requires some shenanigans with the headers of the response, since
Feathers/Express likes to augment the Content-Type with the charset field. The
charset field throws dredd off for some silly reason, so this might trimming in
some express middleware later
I'm still noodling through how the eventbus HTTP API should look. My current
thinking is that it should approximately support Kafka like semantics, since
that's the likely first "real" backing implementation of eventbus
Still not really doing anything worth a damn, but at least we're grabbing the
manifest and doing something with it at this point.
I still don't know squat about rust
I clearly don't know anything about Rust thus far, but was just experimenting
with what it might look like to build an agent that requests JSON over HTTP
might look like.
R Tyler Croy