Conversation
The "Create GitHub Release" step's condition checked steps.check_tag.outputs.exists, but the "Check if tag already exists" step never sets an output named exists - it only ever sets skip (and only when the tag already existed). So steps.check_tag.outputs.exists was always empty, the condition always evaluated false, and the release-creation step was silently skipped on every run. Confirmed via the Actions run history: tags v1.2.9 through v1.3.2 were all created successfully, but no GitHub Release was published for any of them - the repo's Releases page has been stuck showing v1.2.8 since April even though the plugin itself moved well past it. Tag creation (which correctly checks the skip output) was never affected. Fixed the condition to check the same skip output the rest of the workflow already uses. This only fixes releases going forward; the four already-missing releases (v1.2.9, v1.3.0, v1.3.1, v1.3.2) need to be created manually since their tags already exist (an automatic re-run would skip them for the same "already tagged" reason it always has). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UPpumFb2PP21ATpDwJBYBB
Reported: searching "Lourdes" added all 17 online search results to new_city.cfg, not just the one city actually chosen. #6 appended every result from search_online to the offline list as soon as the search ran, before the user picked anything. Moved the write to the four places a city is actually selected instead (ok/save_favorite1/save_favorite2/save_home), keyed off the exact same get_selected_city() string already used to save favorites - same format as the offline file, so no extra parsing/round-tripping. Still deduped by id so repeated selections don't grow the file. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UPpumFb2PP21ATpDwJBYBB
pQu4k3r
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two unrelated fixes landed on
developwhile this PR was open, so both are included here.1. Autotag workflow: GitHub Release step never actually ran
User reported the repo's Releases page was stuck on v1.2.8 despite the plugin having moved well past it. Root cause found in
.github/workflows/autotag.yml.The "Create GitHub Release" step's condition checked
steps.check_tag.outputs.exists, but the "Check if tag already exists" step never sets an output namedexists— it only ever setsskip(and only when the tag already existed). Sosteps.check_tag.outputs.existswas always empty, the condition always evaluated false, and the release-creation step was silently skipped on every single run (conclusion: skipped, confirmed via the Actions run history), while the overall workflow still reported success.Tag creation was unaffected (it correctly checks
skip) — confirmed vialist_tags: v1.2.9, v1.3.0, v1.3.1, and v1.3.2 all have tags, butlist_releasesshows none of them ever got a published Release. The bug has been present since at least v1.2.9 (mid-July), well before this session's work.Fix: one-line change, use the same
skipoutput the rest of the workflow already checks.Note — does not backfill history: this only fixes release creation going forward. The four already-missing releases (v1.2.9, v1.3.0, v1.3.1, v1.3.2) can't be recreated by simply re-running the workflow, since their tags already exist and the
skipcheck would treat that as "already handled." Backfilling those needs either manually creating releases for the existing tags via the GitHub UI, or deleting and recreating a tag to force a re-run (not done here — destructive action on published history).2. city_panel.py: offline city list saved every search result, not just the selected city
User reported: searching "Roma" added all 17 online search results to
new_city.cfg, not just the one city actually chosen. The auto-create-offline-list feature added in #6 wrote every result fromsearch_onlineto the file immediately, before the user picked anything.Fix: moved the write to the four places a city is actually selected (
ok/save_favorite1/save_favorite2/save_home), keyed off the sameget_selected_city()string already used to save favorites — same format as the offline file already expects. Still deduped by id.