Adds "skip" as a new testcaserun finished outcome

[dan-han-101]

Changes

Adds "skip" to the set of possible outcomes for a testcaserun.finished message. A final outcome of "skip" is common for many test frameworks, so adding it as a possible outcome will improve interoperability.

See further discussion in #140.

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Has the primer doc been updated if a design decision is involved
• Have the JSON schemas been updated if the specification changed
• Has spec version and event versions been updated according to the versioning policy
• Meets the CDEvents contributor standards

I clicked on all of the links in the submitter checklist, but some seem sort of stale or not very applicable.

[afrittoli]

@dan-han-101 Emil will be back from PTO the second week of August - is it ok to wait until then?

[dan-han-101]

Sure, it's no problem .
Thanks for checking in.

[e-backmark-ericsson]

As mentioned in a comment on #146 I believe we need to gather a common view on what it means that a test cases is skipped vs canceled or aborted. It could be fine to add a skip outcome value to testCaseRun.finished, but I don't think it should be used to signal that a testcase execution was never even started.

[afrittoli]

@dan-han-101 thanks for the updates! It looks like the examples need to be updated as well - see the outcome of the CI job.

[dan-han-101]

@afrittoli - anything else I can do to help land this one? Thanks!

[e-backmark-ericsson]

@afrittoli - anything else I can do to help land this one? Thanks!

Please make sure all unresolved conversations are sorted out and then resolved: https://github.com/cdevents/spec/pull/145/files#conversations-menu

[e-backmark-ericsson]

There are a couple of mentions of the environment property left in example and schema, which I believe should not be there for the skipped event. Apart from that this PR looks ok to me now.

[afrittoli]

The latest iteration looks good to me, thank you for your work on this @dan-han-101.
@e-backmark-ericsson @xibz wdyt?

[xibz]

@dan-han-101 Thanks for the updates! This looks good :)

[dan-han-101]

Hello. it looks like this one is now blocked because all commits need to be signed.

I'm not sure what's the best path forward here, as I'm not familiar with signing commits.

Would it be OK for me to squash all my commits, so that this PR only has a single commit, that I will make sure is signed?

Or is there an easy way to add sign off to old commits?

Or, could someone else merge this PR, by squashing all commits, and signing the finally commit ?

[afrittoli]

Hello. it looks like this one is now blocked because all commits need to be signed.

I'm not sure what's the best path forward here, as I'm not familiar with signing commits.

Would it be OK for me to squash all my commits, so that this PR only has a single commit, that I will make sure is signed?

Or is there an easy way to add sign off to old commits?

Or, could someone else merge this PR, by squashing all commits, and signing the finally commit ?

Thanks @dan-han-101, sorry about the extra step 🙏
I would appreciate it if you could squash the commits and force-push. Alternatively, you can git rebase -i, mark all unsigned commits for edit and sign them with git commit --amend. Stack exchange suggests doing something like this, which seems reasonable:

git rebase --exec 'git commit --amend --no-edit -n -S' -i HEAD~<# of commits from HEAD you need to update>

so, probably in your case, it would be:

git rebase --exec 'git commit --amend --no-edit -n -S' -i HEAD~13

and then force-push.

[dan-han-101]

@afrittoli - I think this is ready to land now. Please let me know if anything else is needed from me.

[afrittoli]

Thanks for your contribution and patience, this looks good now!