DATA: RunUntilFailureTask

[mabroukmahdhi]

closes #141

[cjdutoit]

Remove all items that is not related to this PR. Only expecting RunDotNetTestsUntilFailureTasks

[cjdutoit]

Suggest a name change so it is clear that it is referring to dotnet test runner

Suggested change

	public class RunUntilFailureTask : GithubTask
	public class RunDotNetTestUntilFailureTask : GithubTask

[cjdutoit]

Suggested change

	[YamlMember(Order = 1, Alias = "shell", DefaultValuesHandling = DefaultValuesHandling.OmitDefaults)]
	public override string Shell => "bash";
	[YamlMember(Order = 2, Alias = "run", DefaultValuesHandling = DefaultValuesHandling.OmitDefaults)]
	public override string Run => "for i in {1..1000};" +
	@" do echo ""Run #$i""; dotnet test --no-build " +
	"--verbosity normal --filter 'FullyQualifiedName!~Integrations' || exit 1; done";
	/// <summary>
	/// Gets or sets the name of the task.
	/// </summary>
	public override string Name { get; set; } = "Run .NET Tests Until Failure";
	/// <summary>
	/// Gets the shell type used to execute the task.
	/// The default value is: "bash".
	/// </summary>
	public override string Shell => "bash";
	/// <summary>
	/// Gets the command to execute for the task.
	/// The command runs a loop that repeatedly executes .NET tests up to 1,000 times
	/// or until a failure occurs. If a test fails, the loop exits with an error code.
	/// The default value is:
	/// "for i in {1..1000}; do echo \"Run #$i\"; dotnet test --no-build --verbosity normal --filter 'FullyQualifiedName!~Integrations' || exit 1; done".
	/// </summary>
	public override string Run =>
	"for i in {1..1000};" +
	@" do echo ""Run #$i""; dotnet test --no-build " +
	"--verbosity normal --filter 'FullyQualifiedName!~Integrations' || exit 1; done";

[cjdutoit]

Might be worth adding a constructor with some default arguments, so you could change the iteration if needed.

I am in two minds about this component. I feel this one might be better as a job component or a job component that uses this task and the reason for this is that this could be a very long running task which will have a time impact and potentially a resource cost impact. I am thinking create a job where you can conditionally trigger this via a tag/label on the PR similar to the TagJob that checks for the presence of the RELEASES as a pre condition for tag and release.

You can then conditionally trigger this via the label only when you need it i.e. when testing flaky or intermittent issues, stress testing, or regression testing but not subjecting devs to time delays for normal routine testing.

Thoughts @hassanhabib / @mabroukmahdhi ?

[mabroukmahdhi]

I will re-implement this differently and create a new PR.