search

cdevents / spec

A common specification for Continuous Delivery events
Apache License 2.0
125 stars 22 forks source link

Adds "skip" as a new testcaserun finished outcome #145

Closed dan-han-101 closed 4 months ago

dan-han-101 commented 1 year ago

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 https://github.com/cdevents/spec/issues/140.

Submitter Checklist

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

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

afrittoli commented 11 months ago

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

dan-han-101 commented 11 months ago

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

e-backmark-ericsson commented 11 months ago

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 commented 9 months ago

@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 commented 6 months ago

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

e-backmark-ericsson commented 5 months ago

@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

dan-han-101 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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