-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
'ID' might be exported but not stored in metadata #1503
Comments
Personally I ignore |
IMO the id should be required, but it's not entirely necessary, it's used mainly for exporting testruns to polarion for case searching (it's more precise than the other 2 methods: tcms case id or beaker-task) This is literally the same as with extra-nitrate field, export generates it but it's not necessary right? well, no, another export would fail when extra-nitrate field is not there and yet there is no forcing the user to btw, on Friday I submitted a PR for import #1502 which could pull the ID from Polarion, so the ID might not be lost to time (and |
No. |
I've seen the code and done multiple imports, but am very interested where/how is this enforced. |
By the enforcing I meant |
Exactly, so it works the same for id parameter. |
Yes but the difference is that all other parameters are generated during |
Well, with the PR I posted it will be generated during import as well. Can add the generation for TCMS import if it will be required, but considering TCMS is supposed to die at EOY, I don't think it's that important. |
I am still not convinced generating |
I believe we have problem with generating 'id' as part of the test export (to polarion/nitrate). It is very easy to export & forget that git was modified so the only place where 'id' is stored is TCMS/polarion. (or plain git reset --hard to get rid of unwanted modifications)
If it is required then it should be created before AND committed to the git (same as other metadata changes).
If it is optional then do not create it as part of the export without explicit request.
Thoughts?
@psss @KwisatzHaderach @hegerj
The text was updated successfully, but these errors were encountered: