New version not downloading

[jaymunro]

Version of the custom_component

0.4.3

Configuration

Installation via HACS using custom repo agittins/bermuda

Describe the bug

The new updates on main added 18 hours ago are not showing as a new version in HACS.
Choosing "Redownload" does a redownload but the code downloaded does not have the new changes (which look great btw)

Troubleshooting further, I see in https://hacs.xyz/docs/publisher that:

• https://hacs.xyz/docs/publish/action shows .github/workflows/validate.yml is needed, but this is not in the Bermuda repo
• https://hacs.xyz/docs/publish/start shows there may be some missing keys in hacs.json:

The default branch main is showing in the download list so "hide_default_branch": true
You mentioned the zip seems it was not being downloaded. This may because the following is needed:

"zip_release": true,
"filename": "bermuda.zip"

I'll change my fork and make a pr

[agittins]

The validation job is already present, in tests.yaml - it does both the HACS validation and the hassfest validation.

It shouldn't show as a new release because... I haven't made a release. 😄 I'll do one when I'm happy with the set of changes and have had time to ensure things work properly.

The reason that hide default branch is not set is so that people who want to stay at the bleeding edge have an easy way to do so (including my production setup), this is why main is (and should be) in the list of "versions".

The note about zip is slightly mis-characterising the discussion - that was about versioning, and uncertainty about whether it was using the zip files or not. AFAICT the versioning is working properly, so I'm not particularly concerned about the zip files, however...

The documentation is unclear about whether using zip releases is preferred or not, and I can't see a compelling case for it given the amount of time I'd have to put in to checking nothing breaks. If you find information that supports using it I'd be happy to take a look, but failing that I'd rather accept the defaults they suggest and work on features instead. 😄

[jaymunro]

Ah, ok. The versioning is still not working for me. manifest.json is still showing 0.0.0 for the version in the installed code. Also in const.py, so I am never sure which version I have running. The HACS interface shows 0.4.3, but that is from the readme.md in your repo, not what is actually in my custom_components directory.

{
  "domain": "bermuda",
  "name": "Bermuda BLE Trilateration",
  "bluetooth": [
    {
      "connectable": false,
      "manufacturer_id": 76
    }
  ],
  "codeowners": ["@agittins"],
  "config_flow": true,
  "dependencies": ["bluetooth_adapters", "device_tracker"],
  "documentation": "https://github.com/agittins/bermuda",
  "integration_type": "device",
  "iot_class": "calculated",
  "issue_tracker": "https://github.com/agittins/bermuda/issues",
  "requirements": [],
  "version": "0.0.0"
}

[jaymunro]

From looking at .github/workflows/release.yaml, I think the version number is written to the files in the zip, hence it is not being downloaded. I guess the download is coming directly from the github repo subfolder. No big deal, just a "nice to have" while there's not many using it.

fyi, choosing main in the version list, is indeed allowing me to see your new updates in the download. I was keen to try it as it seems it may fix the sensors getting stuck as 'unavailable' when a device is away and not picking them up until a reload of the integration.

I'll close this so as to stop bothering you.

[agittins]

The HACS interface shows 0.4.3, but that is from the readme.md in your repo, not what is actually in my custom_components directory.

No, the HACS interface is the one to use, I believe. It doesn't come from the readme, it shows you what you are currently running. Eg, if I choose the main branch, after it's installed it shows the commit version in that field:

It's annoyingly bad at updating though, I think it might only update after you restart HA or something.

I think what HACS is doing is it looks at the releases in the repo, and then it downloads the revision as at that release, hence why the manifest doesn't include the version. But it will show in the info page the version that it is based on. This is odd in that it's downloading something that isn't verifiably what it says it is, but I sort of get the intent. I'd prefer it if the release workflow created its own branch and committed the versioned files back to the repo, so that the tagged commit really is bit-wise identical to the zip file and the main branch has no version number in it, but it doesn't and I can't justify the time right now to sort it out. Instead, my "official" position is "look at the version in the HACS UI".

I'm happy to look at any solution that's fully-baked and backed up by the maintainer of HACS or the cookie-cutter template, but I don't want to sink more time into it. For example, the linting issue has taken hours of my day today because fixing these things is often a bit deeper than it first seems - eg the version of black being used varies depending on whether I'm running it locally (system version) or in the venv, or if git is running it, or if vscode is running git which is running it, then github's workflow also makes it's own choice. There are bug reports older than our cat regarding whether vscode should use the same venv for git as the user is using, and they are still "thinking about how to have a discussion about it". There are sensible solutions to it all I am sure but finding the "obvious path" is not always easy!

Then you get a maintainer who writes a tool with a stated singular goal of avoiding merge conflicts, and all of a sudden decides their tool is also going to do formatting of whitespace, and acts like a douchebag to anyone who questions it, so now I need to learn how to configure and use a different tool that has opinions about how to sort imports - and noting that previously I didn't learn how to use the other tool because I'm just using project boilerplate from the cookiecutter template because nobody has enough time to know all the things.

Sorry for the rant, just wanted to vent about those upstream shenanigans.

I think that if you're using the HACS UI then looking in the manifest for the version is "incorrect" and HACS doesn't want you to do that. It feels a bit like a bug in HACS to me - if it wants to call it a certain version, it should download the release of that version, if it wants to pull from the repo it should probably reflect that it's doing that in the ui. Setting the zip release option might do that, but I've had enough meta-work for this month! 😁

may fix the sensors getting stuck as 'unavailable' when a device is away and not picking them up until a reload of the integration.

Hopefully it does - there were some issues I was having with sensors not updating after a restart that only came good with reloading the integration - that at least should be fixed so hopefully it sorts out the issue you had which sounds like it was fairly similar.