Create GitHub Issue Forms

[michael-valdron]

Description of Changes

Replaces current devfile issue templates with GitHub issue forms to simplify and streamline issue creation.

Related Issue(s)

resolves #1141

Acceptance Criteria

New testing and documentation issues can be opened under devfile/api/issues.

You can check the respective criteria below if either of the following is true:

• There is a separate tracking issue opened and that issue is linked in this PR.
• Testing/documentation updates are contained within this PR.

If criteria is left unchecked please provide an explanation why.

• Unit/Functional tests

• QE Integration test

• Documentation

• Client Impact

Tests Performed

Used fork to test issue creation and form validation.

How To Test

Pull changes into fork and switch fork default branch to branch with changes, ensure issues on fork repository is enabled.

Ensure your fork has the labels you want to test, CI applied labels won't work in the fork

Notes To Reviewer

N/A

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: michael-valdron

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[michael-valdron]

/area api

[michael-valdron]

/area ci, /area documentation

[openshift-ci]

@michael-valdron: The label(s) area/ci,, area//area cannot be applied, because the repository doesn't have them.

In response to this:

/area ci, /area documentation

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[michael-valdron]

Will need to change the areas multi-choice dropdown to a textarea as putting the labeling commands separated by commas, a limitation with issue forms, will not trigger complete labeling as seen in my testing: #1703 (comment)

[michael-valdron]

/area ci , /area api

[openshift-ci]

@michael-valdron: The label(s) area/,, area//area cannot be applied, because the repository doesn't have them.

In response to this:

/area ci , /area api

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[michael-valdron]

/area api, ci

[openshift-ci]

@michael-valdron: The label(s) area/api, cannot be applied, because the repository doesn't have them.

In response to this:

/area api, ci

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[michael-valdron]

Will need to change the areas multi-choice dropdown to a textarea as putting the labeling commands separated by commas, a limitation with issue forms, will not trigger complete labeling as seen in my testing: #1703 (comment)

Adding spaces does the trick #1703 (comment), however it still produces an error not ideal every time an issue is created.

[Jdubrick]

Just a few nits, also I can't open issues on your fork to see what each field is so if any suggestion doesn't make sense you can dismiss it (since I couldn't check)

[michael-valdron]

also I can't open issues on your fork to see what each field is so if any suggestion doesn't make sense you can dismiss it (since I couldn't check)

@Jdubrick You'll need to pull changes into a branch in your fork and set it to the default if not already.

[thepetk]

lgtm in general, left only a comment in regards to the emergency registry promotion.

[thepetk]

Might be good here to include all registry promoters? E.g we could create a specific team in devfile org and mention/ping the team if such request is received? WDYT?

[Jdubrick]

Would https://github.com/orgs/devfile/teams/devfile-services-team work?

[thepetk]

Not sure, because the registry promoters are a sub-group of this team.

[michael-valdron]

To follow up here, though I think this would be a good idea, I don't believe you can add a GH organization team as an assignee. Closest solution here is that we can add registry promoters individually to all these issues, though the clean up of assignees might not be ideal, other solutions I can think of are:

• To assign the registry service owner (currently myself, as I currently have it), I could re-assign to promoter on duty and best for getting noticed
• No assignees, we'll have to manually assign the promoter on rotation after any of these are created

[thepetk]

To follow up here, though I think this would be a good idea, I don't believe you can add a GH organization team as an assignee. Closest solution here is that we can add registry promoters individually to all these issues, though the clean up of assignees might not be ideal, other solutions I can think of are:

• To assign the registry service owner (currently myself, as I currently have it), I could re-assign to promoter on duty and best for getting noticed
• No assignees, we'll have to manually assign the promoter on rotation after any of these are created

I think you're right, I don't think there's a way to assign a gh org team. However, to clarify I meant to mention the gh org team in the issue description. This way all promoters get pinged, which could be of help in case some of us are off.