-
-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft design for the matrix context? #532
Conversation
I can't run the project for now because of a timeout
> Could not download binary-compatibility-validator-0.12.1.jar (org.jetbrains.kotlinx:binary-compatibility-validator:0.12.1) does that ring a bell? https://scans.gradle.com/s/ymfeu563hrxfc/failure#1
on = listOf(Push()), | ||
sourceFile = Path.of("some_workflow.main.kts"), | ||
) { | ||
val matrix = object : StrategyMatrix() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you considered making the strategy one of workflow
's arguments, like it's done now in the simplified implementation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to be honest, I am not a fan that workflow()
, job()
have like 10 parameters each already
some could be part of the JobBuilder /WorkflowBuilder DSL instead IMHO
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These approaches have both pros and cons. Some of the pros of the argument approach I see:
- better discoverability in the IDE - the users are more likely to discover an argument than some extra DSL piece
- compile-time enforcement of having this matrix defined just once in a well-defined, canonical place
One of the cons is sure the number of arguments which starts to become hard to maintain.
Let's defer this decision until we have a better understanding on the features we want to implement.
return Property(value.map { it.toString() }) | ||
} | ||
|
||
public fun objects(vararg value: Map<String, String>): Property { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The objects can have also non-string attribute values.
@jmfayard thanks for starting working on it! IMO first we should enumerate all features of GitHub strategies, understand them well (with some examples in YAML), decide which ones we want to implement (let's start with "all"), and then propose examples how each of them is covered in the DSL. Does it make sense? |
yes absolutely, that's also what I had in moind. |
Please reopen if needed. |
See #368 and #297
This is just a draft of what the API looks like.
I didn't try to generate the YAML correctly, and there are some features of the matrix that I don't really understand, like having objects, include (not supported) and excludes
wdyt?