Feature Request: Redownload non-default branch

[jhansche]

System Health details

System Information

version	core-2023.9.3
installation_type	Home Assistant Supervised
dev	false
hassio	true
docker	true
user	root
virtualenv	false
python_version	3.11.5
os_name	Linux
os_version	6.1.0-12-amd64
arch	x86_64
timezone	America/New_York
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
GitHub API Calls Remaining	4958
Installed Version	1.33.0
Stage	running
Available Repositories	1302
Downloaded Repositories	16
HACS Data	ok

Home Assistant Cloud

logged_in	false
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Home Assistant Supervisor

host_os	Debian GNU/Linux 12 (bookworm)
update_channel	stable
supervisor_version	supervisor-2023.09.2
agent_version	1.6.0
docker_version	24.0.6
disk_total	467.0 GB
disk_used	89.5 GB
healthy	true
supported	true
supervisor_api	ok
version_api	ok
installed_addons	Mosquitto broker (6.3.1), File editor (5.6.0), InfluxDB (4.7.0), Grafana (9.0.3), Let's Encrypt (4.12.9), NGINX Home Assistant SSL proxy (3.5.0), Z-Wave JS UI (2.0.1), Studio Code Server (5.10.2), Node-RED (14.5.0), SQLite Web (3.9.3), ESPHome (beta) (2023.9.1), ESPHome (dev) (dev), WeatherFlow to MQTT (3.2.1), Matter Server (0.3.0), CHIP Tool (0.2.1), CHIP Controller REPL (0.4.0), Home Assistant Google Drive Backup (0.111.1), Matter Server (4.9.0), MariaDB (2.6.1), Network UPS Tools (0.12.1), Piper (1.3.2), Whisper (1.0.0), Advanced SSH & Web Terminal (15.0.8), Docker Wyze Bridge (2.3.17), Frigate (0.12.1), Docker Wyze Bridge (DEV branch) (dev), Music Assistant BETA (2.0.0b73), Glances (0.19.3), ESPHome (2023.9.1)

Dashboards

dashboards	5
resources	4
views	25
mode	storage

Recorder

oldest_recorder_run	September 2, 2023 at 3:01 PM
current_recorder_run	September 26, 2023 at 10:33 PM
estimated_db_size	3751.23 MiB
database_engine	mysql
database_version	10.6.12

Spotify

api_endpoint_reachable	ok

Checklist

• I'm running the newest version of HACS https://github.com/hacs/integration/releases/latest
• I have enabled debug logging for my installation.
• I have filled out the issue template to the best of my ability.
• I have read https://hacs.xyz/docs/issues
• This issue is related to the backend (integration part) of HACS.
• This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
• This issue is not a duplicate issue of currently open or issues pending release.

Describe the issue

This idea is inspired by the way the ESPHome supports external_components configuration, particularly being able to link directly to a GitHub PR:

external_components:
  - source: github://pr#1234
    components: [ my_component ]

Today when you select a repository > ⋮ > Redownload, you are presented with a couple possible views:

1. The repo has no releases. In this case you see only a Download button, and it just re-downloads the default branch (main).
2. The repo does have releases. Here you see the checkbox to enable "beta" versions or not, and a select list showing the last 5 versions, as well as the default branch (main) if beta is checked.

What would be useful is an additional option here - maybe only if advanced/experimental features are enabled, and maybe only if the "beta" checkbox was enabled - to select or enter a PR # to use, or list other branches aside from the default branch (could be limited as well, to avoid overwhelming the UI for active projects).

The goal would be for an integration author to prepare a new branch (and maybe even create the PR from it) and ask for testers in the original issue or PR. Users would be able to test it quickly just by entering the PR number, or selecting or entering the test branch name. From there, same rules apply (restart required, and so on). The user tests the functionality, reports results back to the issue or PR, and then the user can go back and switch back to the default branch or the latest version and wait for the fix to land.

I did see one discussion about this on Discord from Mar 2023, where your feedback was that it should not be used for temporary things. I understand not wanting to potentially leave users in a bad or orphaned spot, but the alternative options are actually more error prone IMO:

• You could tag the PR branch with a temporary tag and publish a "Prerelease" for that. This makes it appear only when "Show beta versions" is enabled. For the sake of keeping things tidy, I would likely want this temporary prerelease tag to be deleted once the issue has been verified and the PR closed, but that is poor git-etiquette.
• Maintain proper versions, and just use the main branch for one-off testing. For repos that are not highly active, this is probably the cleanest approach, but it comes at the expense of writing possibly broken commits into the main branch, which is also poor git-etiquette (and/or amending commits and force-pushing, which is also poor git-etiquette).
• The last option is to force the user to do it all the manual way. For developers this isn't a huge deal, but for end-users who may be the best (or only) ones suited to verify a fix, this could be a hard pill to swallow.

---

Note: I read the Issues page, and also looked over the available templates, but unfortunately I did not see any information about "feature request" issues. So, apologies if this is insufficient for a feature request, feature requests are not accepted, or if feature requests are meant to go someplace else 😬

Reproduction steps

1. Add the integration custom repo
2. Open github issue for integration repo
3. Integration owner prepares a fix and asks for help testing

Debug logs

No logs: feature request.

Diagnostics dump

No response

[hacs-bot]

Make sure you have read the issue guidelines and that you filled out the entire template.

If you have an issue identical to this, do not add comments like "same here", "i have this too", instead add a 👍 reaction to the issue description. Thanks! 👍

[ludeeus]

I’m currently not taking feature requests (which is why you did not find a place for it).
What you are suggesting will come in form of enabling the version key for the update entities.

[jhansche]

Thanks for the response - apologies for not knowing that you aren't taking feature requests 😳

Just to clarify, when you say "will come" - does that mean this is an upcoming feature already planned in HACS, or just a note about what it would take in order to achieve that? Or is that something that is already possible but I've just missed it somewhere?

Not fully understanding, and on the hope that it means the latter, I tried to call update.install, with the HACS-created update entity for my integration, and passing the temporary branch as the version key, which is what I inferred from the comment. That resulted in Installing a specific version is not supported for <update.entity>, and I see that happens when the update entity does not support UpdateEntityFeature.SPECIFIC_VERSION = 2, which appears to be expected because the HACS update entity only supports INSTALL | PROGRESS | RELEASE_NOTES.

So I guess that leaves the other two options: is that something that is planned, or was that comment just an FYI?

[ludeeus]

It is planed to be implemented I just have not yet gotten around to actually do it yet.
But before I release 2.0.0 it will be there.

[jhansche]

Awesome! Thanks for the quick response.

[ludeeus]

FYI: #3301