Add an actionButton property to the SourceControl api

[eamodio]

Refs: #110882

This proposal adds a new actionButton property to the SourceControl object, to allow SCM extensions to contribute a large "cta" style button to a repository.

Here is the proposed api addition:

export interface SourceControl {
	actionButton?: Command;
}

This is currenty being used by the built-in Git extension to provide the "Publish Changes" or "Sync Changes" button when there are unpublished or unpushed commits.

[mattseddon]

@lszomoru is there any plan for this to become available in the stable API?

I'd like to use it in the DVC Extension for VS Code.

Use case is here: iterative/vscode-dvc#1769.

Some high level details about the extension can be found at microsoft/vscode-discussions#54.

[lszomoru]

@mattseddon, thanks for the interest in the Action Button. The last two milestones we evolved the shape of the property in order to accommodate the "Commit" action button. I think that soon we will reach a phase where we can look at finalising the API.

[DavidGoldman]

Any update on this becoming stable?

[lszomoru]

@DavidGoldman, no progress was made in finalising the action button. Sorry.

[anandbibek]

+1 to get this API

[vasilev-alex]

@lszomoru if I'd like to go the hard way (e.g. copy/pasting some code from the git, git-base extensions) would it be possible to add that button? Or, implementing a custom "Sidebar" is the only way?

[lszomoru]

@vasilev-alex, I do not believe that taking code from the git or git-base extension will get you there. In case your extension is using a Webview, you could use the Webview UI Toolkit.

[gjsjohnmurray]

@vasilev-alex if you are prepared to tolerate the constraints imposed on extensions that used proposed API (i.e. can't publish on Marketplace, and even after install from VSIX require a command-line argument to be specified each time or alternatively added to argv.json) then I recommend this route.

@lszomoru I sincerely hope this proposed API isn't going to follow the example of several others which have languished in proposed state for many years, often with no refinement occurring during that time, and giving IMO an unfair advantage to certain "blessed" extensions that are permitted to use them without having to overcome the constraints mentioned above.

Are there specific reasons for not finalizing this one?

[gjsjohnmurray]

Thinking out loud here, I wonder what the answer would be if someone with a subscription asked GitHub Copilot what it'll take to get a proposed API finalized.

[lszomoru]

@gjsjohnmurray, thanks for the continued feedback. The proposal for the action button has evolved since its inception (ex: added description, and secondary actions). One aspect that we still have to decide on before finalization is what's the best approach for defining secondary action (ex: code vs. menu with static contributions).

[gjsjohnmurray]

I would prefer secondary actions to be contributed by code. Having to predefine options in settings.json is a significant restriction the UX our Deltanji SCM extension can provide. Deltanji provides highly configurable workflow, so when we build our extension we cannot know which transfer routes a Deltanji site will want to offer to its devs.

Of course, if our longstanding wish for dynamic (sub)menu support were granted then it would probably be fine for secondary actions to be implemented as a menu.