It looks like the docker credentials are incorrect, because
builds are failing with an auth problem. For example build 2.0.0-preview7.1704:
https://ci.appveyor.com/project/sfmskywalker/elsa/builds/38438996#L6715
This can be re-enabled once the auth issue is fixed. There should be
no real harm in disabling it, since it's not working at the moment anyway.
It seems that some work done in these commits, for the
file ForEachBuilderExtensions was responsible:
* 4807ace13c
* dfbba1e176
A couple of the extension methods were missing out a ToList()
which later caused an ArgumentException when setting a property
value via reflection.
I also added an extra exception for the set-value logic. This way,
if/when there is a problem, the exception will indicate which property
it was trying to set at the time.
This replaces the `Then(string activityName)` method with `ThenNamed(string activityName)`.
A new method is added to allow connecting to activities by type name: `ThenTypeNamed(string activityTypeName)`.
The reason for this change and addition is to allow workflow builders to connect to activity types that do not have a corresponding type.
For example, the Telnyx project has an activity type provider that *dynamically* provides activity types based on Telnyx webhook callback types.
This means that the model:
* Implements IConvertible so that Jint may implicitly convert
it to other types as if it were just a string.
* The Values & Values properties are perhaps a little less confusing
now, and present a more consistent set of state, regardless of
the inner model.
* There's a minor simplification to ToString, since String.Join already
did what we wanted for one or many values.
Notable though is - because this class implements IConvertible,
it is no longer CLS compliant. We do not currently mark this assembly
as CLS complient so as things stand that's OK. I do not know if there
are any plans/expectations for CLS compliance in Elsa.
If we do plan to mark the assemblies as compliant then we must mark this
class [CLSCompliant(false)].
The issue here is that the elsa.db for sqlite is going in the same
path every time. Depending on the order in which tests are run,
sometimes it means that migrations are run on a DB which is
expected to be empty but which already exists. That causes an
error & test failure.
Here I've just used temp folders to ensure that the DB file is in a
different path every time.
One of these tests is failing and this is the one which
demonstrates issue #738. The composite activity which begins
with ReceiveSignal doesn't generate a trigger.
