Complete draftIssue and add slash commands to default config

[justinmilner1]

Description

Resolves:

• The slash commands /http and /issue don't work. #1036

Related bug: #1035

• /so is waiting upon re-initialization of external server (I didn't re-add it)

I added:

• interfacing with github create issue API
• default config setups for /issue, /http, and /commit (otherwise they don't show up in drop-down menu until user manually adds them to their config)

Evidence:

On gitlab:

[pzaback]

It looks like this actually overlaps in a way with this PR I submitted to resolve the fact that referencing params wasn't working for any existing slash commands: #1084
I had also identified as you did here that this.params also works, but given that multiple examples omitted "this", I went searching for a root cause and it seemed like the issue was that params were mapped elsewhere as "options" instead. I don't know if one or the other is "more" correct, but just thought it worth mentioning in case there are some potential foot-guns with either that I'm not aware of.

[sestinj]

@justinmilner1 Part of the goal with generating a link was to give users a chance to modify the issue before it originally gets published. When you create via API, I think it just immediately creates the issue, is this how that works? I think it would be nice to have a verification flow where users don't need to fear that the model outputs something scary without a chance to review. Can you think of any kind of in between solution? I don't know if there's an API for generating drafts, or if perhaps we just need to generate a more obvious link (possibly an h1 with a link rather than the small text at the bottom, or just better messaging, like "please click here to create the issue")

[justinmilner1]

@pzaback Good catch! Just tested and pushed up your fix to avoid using 'this'.

@sestinj I definitely agree. Feels very wrong to publish the issue without manual editing or confirmation, even if the issue is heavily labeled a draft. ...Unfortunately, github doesn't have a draft option for issues currently.

I think two changes should be made:

1. A 'publish' button should be added into the chat bar. Alternative could be a code lens in the generated issue.

2. The draft should be generated in a new editor, rather than in the sidebar. This way the user can edit the generated issue as they wish.

These are fairly heavy changes but I think they're necessary for this feature to really be valuable.

Any thoughts?

[sestinj]

@justinmilner1 it's not a direct API that they have, but you can create a URL that opens up a draft of an issue when clicked. This is what I was going for with the link at the bottom of the slash command (

continue/core/commands/slash/draftIssue.ts

Lines 51 to 53 in 98521a2

	const url = `${params.repositoryUrl}/issues/new?title=${encodeURIComponent(
	title,
	)}&body=${encodeURIComponent(body)}`;

)

As an example: https://github.com/continuedev/continue/issues/new?title=Testing&body=HelloWorld

I think you're right though that it would be nice to have more prominent button. I wonder if there's a method of creating buttons in markdown. If this was possible it would be useful in many other slash commands as well. In StyledMarkdownPreview.tsx we use rehype/remark and they both have really great plugin ecosystems. It might be that there's an existing plugin solution we could use, and if not it could be possible to write something that would convert something like <a href="https://github.com/continuedev/continue/issues/new?title=Testing&body=HelloWorld"><button>Draft Issue</button></a> into an actual button

[justinmilner1]

@sestinj Ah I think I understand where my confusion is coming from:

When I click on the link you provided, I am not taken to a draft page - instead I'm directed to the template page. When I use the issue feature on the preview branch, it takes me to 404.
If I try to create this 'draft issue' on a repository that I own, I am indeed taken to a 'draft' page.

I added issue templates to my repository, and still am able to reach the draft page - so I think the ability to draft the issue is indeed about repository ownership.

Note: The api is able to create issues both on repos I own and don't own.

So what to do?:
While I wish their was a native gitlab issue draft feature, I do think the 'Publish Draft' button design is sufficient confirmation to create an actual issue, if the issue is labeled 'draft' (in the title/body) and a window is opened with the url for the generated draft - would you agree?

Is it worth it?:
This is a lot of additions - however, I could see this interactivity within chat through buttons being used for numerous other features. Most user-guided interaction with external APIs will need some form of confirmation/rejection.... if this is something to build we should probably have a longer discussion about this.

[sestinj]

@justinmilner1 Oooh this explains everything, I hadn't realized that at all. A bit unfortunate, but nevertheless I think the larger point about user confirmation/input is important. I would say this is interesting enough that we should go ahead and try it. Probably the first attempt won't be the exact thing that lasts forever, but would love to experiment.

The first problem to solve is probably just how to best display a button from the markdown view, and once that is accomplished, rather than making some large refactor so that slash commands can emit buttons in a general way, it might be good to just do something that allows for this to be tested more immediately

[justinmilner1]

@sestinj Got it. I'll experiment with how the button could be displayed.

[justinmilner1]

@sestinj Looks like it's very easy to render a button in markdown - but it's not straightforward how the button's functionality would be initialized, or how slash commands would listen for button activity, or how we would track issue generations to button activity.

My takeaway is that it's something which could be done - and that's good to know! ...but I think it's better to wait until we have more (quantity and importance) use cases for a change this large - what do you think?

[sestinj]

@justinmilner1 I agree with the conclusion. Let's close this PR then, but link it for future reference. I've created an issue (#1264) that I believe describes where this work will go next, but please add any context I might have left out!