Temporal activities no longer have a generalised extension method
for registering them with a service collecton. It is still static and has
the same rough shape as an extension method. This way it is less
visible and less likely to be called by accident.
Also in-line with changes in this branch, things have been renamed
Timers → Temporal
The project/NuGet package for implementation logic relating to
temporal actions has been renamed:
Elsa.Activities.Timers.Hangfire → Elsa.Activities.Temporal.Hangfire
Elsa.Activities.Timers.Quartz → Elsa.Activities.Temporal.Quartz
Whilst large numbers of C# files are "changed" by this commit,
it's just a straight move to a new path.
The project/NuGet package for common logic relating to
temporal actions has been renamed:
Elsa.Activities.Timers → Elsa.Activities.Temporal.Common
Whilst large numbers of files are "changed" by this commit,
it's just a straight move to a new path.
I'm a little confused as to how this happened. It could
relate to an exit code sent by SonarScanner.
I'm going to combine these two commands into a single step
so that if SonarScanner drops a non-zero exit code, it should
still continue on past it.
It actually turns out that no change is required to the SignalReceived
activity in order to achieve this. As these unit tests prove & document,
that is already the current behaviour.
This is not so much about formally launching a
package, it will complete the testing of #664.
Part of that ticket can only be tested by pushing
a tagged commit to the 2.0 branch.
The before_package step doesn't seem to be run, despite being
documented at https://www.appveyor.com/docs/appveyor-yml/
I've moved this step to after_test, which will work just fine.
It's just frustrating that really it's got nothing to do with testing.
The main things going on here in the YML are:
* Adding some env vars for SonarScanner
* Adding the SonarScanner package as a build tool
* Adding before-build/after-test steps to setup/teardown SonarScanner
* Separating the "pack" step from the "build" step
* Pack moved to before-package which occurs after tests pass
* See https://www.appveyor.com/docs/build-configuration/#build-pipeline
* Tests run with logging & code-coverage detection
* Test results are added as AppVeyor artifacts
Adds an XUnit test logger to each test csproj
file (will be used by test script).
Also add a skeleton SonarCloud analysis config file with a couple
of settings for starters: Don't analyse exception classes or samples
for coverage.
This reverts commit 3dc1b79b3b, reversing
changes made to 1dbafd8ba2.
The previous merge of work on #665 broke the build so this commit
reverts it back out.
The main things going on here in the YML are:
* Adding some env vars for SonarScanner
* Adding the SonarScanner package as a build tool
* Adding before-build/after-test steps to setup/teardown SonarScanner
* Separating the "pack" step from the "build" step
* Pack moved to before-package which occurs after tests pass
* See https://www.appveyor.com/docs/build-configuration/#build-pipeline
* Tests run with logging & code-coverage detection
* Test results are added as AppVeyor artifacts
Adds an XUnit test logger to each test csproj
file (will be used by test script).
Also add a skeleton SonarCloud analysis config file with a couple
of settings for starters: Don't analyse exception classes or samples
for coverage.
This is a bit of naughty scope-creep on that issue.
I noticed that there's some further parts of the YML which
are duplicated between the two v2 sections of the YML.
It seems that the intent is mainly about deploying to MyGet on
every build (in the appropriate branch) but only deploying to NuGet
if building from a tag. Also, the actual build steps between these two
seem to be out of sync.
I've switched to a more concise way of achieving this same result,
which allows me to de-duplicate the two build configs so they're using
the same build process.
The only other real thing I did there was sneak in the autocrlf git
setting. It's just a good idea on Windows to avoid being caught out.
It was irking me that when I clicked on the badge to get
to the latest CI build, I'd get an error that the project didn't exist.
Fixes the URL to AppVeyor to see the latest build.
This also fixes the status image to the v2 branch. Once v2 is in master
that querystring param fixing it to a branch should be ditched.
* Add WorkflowExecutionBurstStarting event to allow for persisting status changes before executing activities that potentially take a long time to finish
* Also persist workflow instance when burst is starting and behavior set to WorkflowPassCompleted
