Use package control version resolution method for tags

[eugenesvk]

I've specified MarkdownEditing:SublimeText-Markdown/MarkdownEditing as an extra-packages in actions/setup and was surprised to see that an ancient 2.2.10 version was installed

Reading the comments more carefully, the action ignores the package control resolution strategy: https://github.com/sublimehq/package_control_channel/blob/b8b340ab5398a7651f6770b656bccd5dda258c09/repository/m.json#L671-L672 , and defaults to basic untagged semver o

If an exact match is not found, the latest tag is determined by semver x.y.z

or forces users to pick a tag (which could break once ST version are updated)

@ref branch/tag name or prefix of tags e.g. st3- or empty

Could the action instead of forcing an explicit specification of a prefix use the Package Control manifest to pick the one that fits the installed Sublime Text version? And then CI users would only need to specify a given package tag to override

[deathaxe]

A rather naive bash logic is used to install extra-packages.

see:

UnitTesting/actions/setup/action.yaml

Lines 204 to 220 in de5a85d

	# Install extra packages to to Packages/<Package>
	while read -r x; do
	if [[ "$x" =~ ^(.*):(.*)/([^@]*)@?(.*)$ ]]; then
	PKG="${BASH_REMATCH[1]}"
	USER="${BASH_REMATCH[2]}"
	REPO="${BASH_REMATCH[3]}"
	SHA="${BASH_REMATCH[4]}"
	elif [[ "$x" =~ ^(.*)/([^@]*)@?(.*)$ ]]; then
	PKG="${BASH_REMATCH[2]}"
	USER="${BASH_REMATCH[1]}"
	REPO="${BASH_REMATCH[2]}"
	SHA="${BASH_REMATCH[3]}"
	else
	continue
	fi
	InstallPackage "$PKG" "https://github.com/$USER/$REPO" "$SHA"
	done <<< "${{ inputs.extra-packages }}"

I can't say anything about the motivation of the current implementation. Just applied at from what's available in legacy /sbin path.

An alternative might be to add extra-packages to Package Control.sublime-settings or directly command a install_packages to use Package Control to install the right one. But this will immediatly remove the option to pin package versions.

[eugenesvk]

Package Control.sublime-settings or directly command a install_packages to use Package Control

Shouldn't this be the default? After all, the users will likely have autoupdate and have the Package Control's current version, so most common testing should reflect that?

But this will immediatly remove the option to pin package versions.

This could remain as an optional alternative? No need to remove it

[deathaxe]

The whole setup stuff is not as straight forward as it could be. Most of it was copied from /sbin and adjusted to work in GH actions, with least possible behavior/implementation changes.

I have no idea about /sbin and /docker stuff still being in use on Travis and co. and I hesitate to make big changes in v1 which might break existing actions as there are quite some packages which make heavy use of the infrastructure.

v1 is in maintanance mode and likely receives crutial fixes to keep it running, only.

All of that would require a v2 to cleanly separate things, but I currently don't have the capacity to push major changes forward.