Hi,
I need some help how to implement the update method "single_file_plugin" because I have that Issue.
I implemented it like the docs said, but now octoprint always tells me a update is available but the ETag strings don't change.
I suspect your issue is the header_name is not case matched to what is returned from GitHub.
Try changing it to Etag
I crated a branch to test that.
The behavior hasn't changed. It still shows always that an update is available.
I saw the issue but don't have time to look deep and investigate at the moment, but one question that did pop into my head if you want to investigate was how does OctoPrint know what the current etag/version is to compare to the one it fetches from GitHub? My suspicion is it's comparing nothing to the etag so it always thinks there's an update. It only has the current version number of your plugin, not the current etag?
couldn't the use of github_commit type work here even in single file plugin approach? I think the logic of the single_file_plugin type might be geared specifically toward gist maybe.
github_release type with single_file_plugin method definitely works.
I may have spoke too soon. Tried doing another release and it's not picking up the update from the py file. Still thinks 1.1.2 is installed even though the update process does indicate it's re-downloading the files from master. I wonder if this is some kind of caching issue.
EDIT: github_commit type does seem to work. I updated the above fork and after making a change it pulls the new version and does seem to keep the commit id(?) from update for comparison. I suspect this might be a potential bug with the httpheader type not storing the header_name value for future comparison the same way github_commit does maybe?