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
* WIP #653 - Delete two tests
These two couldn't easily be fixed, in both cases they were
integration tests which involved passing through many classes.
It wasn't immediately clear what needed to be done to fix them.
As noted in the issue description, removing them was an
acceptable fix.
* WIP #653 - Fix a failing test
I split this test into two. Per the discussion at:
https://github.com/xunit/xunit/issues/350
XUnit seems quite opinonated about not having assertion messages.
Thus, without changing assertion library (which deserves discussion
before I just do it), the logical next best thing is to split into two
single-assert tests, so it's clear which assertion failed on a test
failure.
Also, I moved the AutoMoqData attribute to the shared test lib, so
that it can be used anywhere. That allowed me to eliminate the
constructor for this test class, except for initialising the base class.
* Provisionally resolve#653 - reinstate tests in CI
This should complete the issue although we need to see a
passing CI build with this code change before we can say
it's done.
* Provisionally resolves#653 - Add test script
* Trivial - Add VS Code workspace
* Trivial - Add VSCode build task & extra ignore
On GNU/Linux, auto-generated .directory
files should be ignored.
* WIP #485 - Boilerplate for unit test project
* WIP #485 - Add test coverage (Remove/RemoveAll)
* WIP #485 - Implement RemoveAll
* Remove redundant logic, covered by IDictionary
Per the following, the contract for a generic IDictionary,
the Remove method already deals with non-existent keys.
https://docs.microsoft.com/en-us/dotnet/api/system.collections.generic.idictionary-2.remove?view=net-5.0#System_Collections_Generic_IDictionary_2_Remove__0_
* Resolve#485 - Add PurgeVariables methods
These are convenience methods upon ActivityExecutionContext
and WorkflowExecutionContext, consistent with their current APIs.
Also in this commit are tests for those simple methods.
There's a bit of test-scaffold as well included, such as:
* Autofixture Xunit2 integration
* New project for unit tests
* Customize attribute for avoiding crashes on Autofixture recursion
* Reusable specimen builder for creating IServiceProvider which
resolves services from Autofixture
* Custonize attribute for a parameter to use that ^^ specimen builder
