You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In this discussion, I'd like to solicit feedback on the design for Broker sequences. These sequences should be thought of as a series of broker commands with accompanying arguments. I'd like to keep the scope as small as possible, but still be useful.
Let's try not to replicate Ansible here :)
The general structure will be a YAML format, with each action being a single element of the overall sequence
Another consideration is the ability to run not just one, but multiple sequences from a specified directory.
If we went this path, then we could specify that scenario files adopt the .scenario extension. This would make identification in a directory much easier.
One important part may be either consolidating output and/or inventory contents. The inventory would be relatively easy to do, but output would be a little more tricky.
That opens up the specification to more meta manipulation..
Calling scenarios should maintain Broker's current parity between CLI and Library usage.
broker scenario multi_execute
With the equivalent library call
Broker.scenario("multi_execute")
However, CLI usage also bring up the possibility of passing additional arguments at runtime for steps, much like we currently can with nicks.
Let's consider the following example:
This is an option, but what if multiple scenarios use the same arguments? Perhaps a way to specify step would be needed, but that seems messy. Alternatively, we could allow users to specify jinja-like variables that a scenario could accept.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
In this discussion, I'd like to solicit feedback on the design for Broker sequences. These sequences should be thought of as a series of broker commands with accompanying arguments. I'd like to keep the scope as small as possible, but still be useful.
Let's try not to replicate Ansible here :)
The general structure will be a YAML format, with each action being a single element of the overall sequence
or run all nicks
Another consideration is the ability to run not just one, but multiple sequences from a specified directory.
If we went this path, then we could specify that scenario files adopt the
.scenario
extension. This would make identification in a directory much easier.One important part may be either consolidating output and/or inventory contents. The inventory would be relatively easy to do, but output would be a little more tricky.
With this, we're flirting on adding more complexity than needed since it would look better to define the file like
That opens up the specification to more meta manipulation..
Calling scenarios should maintain Broker's current parity between CLI and Library usage.
With the equivalent library call
However, CLI usage also bring up the possibility of passing additional arguments at runtime for steps, much like we currently can with nicks.
Let's consider the following example:
How would we allow a user to specify the repository and pr_number arguments at runtime?
This is an option, but what if multiple scenarios use the same arguments? Perhaps a way to specify step would be needed, but that seems messy. Alternatively, we could allow users to specify jinja-like variables that a scenario could accept.
Beta Was this translation helpful? Give feedback.
All reactions