-
Notifications
You must be signed in to change notification settings - Fork 3
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
Use create() instead of new() when processing templates #30
Conversation
522c0b6
to
c63f656
Compare
c63f656
to
25f851d
Compare
edacace
to
c64fb1a
Compare
Fields in simple fields (fields we never modify) were not being pasted to output dict, making it difficult to write tests
Does not include multiple projects since our test data doesn't have multiple projects and isn't written that way at the moment. The pycontribs/jira project utilizes a test environment which spawns an instance of Jira Server live during CI. We may want to consider pivoting how we do CI to that model so we don't keep having to fabricate what Jira would do.
c64fb1a
to
d55895e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple very much non-blocking things, I would merge as-is unless you feel strongly about either of those.
def issue_metadata(self, issue_type_or_id): | ||
def issue_metadata(self, issue_type_or_id, project_key=None): | ||
if not project_key: | ||
project_key = self.project_name | ||
itype = None | ||
for issuetype in self.issue_types: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue (non-blocking): We're iterating through the default project's issuetypes even when getting metadata from a different project. This only works as expected if the issuetype in question is in the intersection of both projects, and names/IDs match for both.
suggestion: I doubt it'll matter in most situations and we can just leave it as an edge case to be filled in once someone actually runs into it. It seems rather obscure and not worth holding up the PR.
reserved_fields = ['subtasks', 'issuetype', 'parent'] | ||
# required_fields are the same | ||
start_fields = {'issuetype': _subtask, 'project': pname} | ||
start_fields['parent'] = parent.key |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit (non-blocking): we can set the parent as we initialize the dictionary, like:
start_fields = {'issuetype': _subtask, 'project': pname, 'parent': parent.key}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's not block for this for now.
suggestion (blocking): Just considered we should also change the issue schema and the example/test templates to use https://github.com/lhh/jirate/blob/master/contrib/example-template.yaml#L2 Otherwise we're stuck in a place where the schema validation wants A conversation for another day is whether having a schema at all still makes sense now that the code looks at required/reserved fields and all. But for now the quick fix will let us merge/tag/release and move on. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #30 (comment)
506f40d
to
fd711e5
Compare
Done. |
With this change, you can use any custom field you could use from the CLI within templates using the
nym
or field name. Ex:story_points
, orfixversions