När en tjänst byter tag ligger det gamla "Update available" kvar för alltid. Exempel: en tjänst kör gitea/gitea:1.27.3 och pollern har registrerat en ny digest under 1.27.3 (available_ref = gitea/gitea:1.27.3). Du deployar sedan 1.28.0, t.ex. via förslaget "Newer tag" från #11 eller via versionslistan. Tjänsten kör nu 1.28.0, men chippet "Update available 1.27.3" står kvar i översikten, och auto-tjänster visar ett förslag som pekar bakåt.
Felet fanns före #11 (en version pick till en annan tag ger samma resultat), men med #11 blir tagbyten vanliga.
Förväntat beteende
Ett förslag från pollern gäller den tag tjänsten följer. När tjänsten följer en annan tag ska available_* tömmas.
Steg för att reproducera
En tjänst kör repo:1.0.0, och registryt får en ny digest under 1.0.0. Efter en poll-cycle visas "Update available 1.0.0".
Deploya repo:1.1.0 från versionslistan, eller med "Newer tag".
Efter jobbet och nästa poll-cycle visas fortfarande "Update available 1.0.0".
Teknisk orsak
FinishJob (internal/master/store/jobs.go) tömmer available_* bara när jobbets to_ref, utan @digest, är exakt lika med available_ref. Ett jobb till repo:1.1.0 matchar aldrig repo:1.0.0.
Pollern (internal/master/poller/poller.go, suggest) grupperar tjänsten under den nya taggen repo:1.1.0. Eftersom ActualDigest == l.digest returnerar den tidigt utan att skriva något, och det gamla available_ref rörs aldrig.
Ingen annan kod tömmer available_*.
Förslag till lösning
Låt pollern tömma ett poll-förslag (available_source = 'poll') när available_ref inte är den ref tjänsten följer nu (jobs.FollowedRef(actual_ref)). Pollern skrev förslaget, så det är pollern som ska tömma det. Det fungerar oavsett hur tagbytet skedde: jobb, manuell docker compose up eller ändrad stackfil. FinishJob och reglerna för när den tömmer available_* lämnas orörda.
Ny store-metod ClearAvailable(id), eller SetAvailable med ett tomt värde. Den skriver bara vid ändring och publicerar events.Services.
Gäller inte borttagna tjänster, tjänster som hoppas över av SkipReason, eller tjänster som följer en tag vars uppslag misslyckades i den här cycle.
Test i poller_test.go och ett integrationstest i store.
Öppen fråga
Webhook-förslag (available_source = 'webhook') kan med avsikt peka på en annan tag än den tjänsten följer. CI kan till exempel säga "1.28.0 finns" om en manuell tjänst som kör 1.27.3. Då är förslaget inte inaktuellt utan själva poängen. Förslag: rör inte webhook-förslag i den här issuen. De töms redan av FinishJob när just den versionen deployas. Behöver de en egen regel, t.ex. "töm om tjänsten redan kör en tag som är lika med eller nyare än förslaget enligt tagver", blir det en separat issue.
Scope
Ingår: att pollern tömmer inaktuella poll-förslag, plus tester.
Ingår inte: webhook-förslag, ändringar i FinishJob, newer_* (#11 hanterar det redan i pollern och när sidan visas).
## Beskrivning
När en tjänst byter tag ligger det gamla "Update available" kvar för alltid. Exempel: en tjänst kör `gitea/gitea:1.27.3` och pollern har registrerat en ny digest under `1.27.3` (`available_ref = gitea/gitea:1.27.3`). Du deployar sedan `1.28.0`, t.ex. via förslaget "Newer tag" från #11 eller via versionslistan. Tjänsten kör nu `1.28.0`, men chippet "Update available 1.27.3" står kvar i översikten, och auto-tjänster visar ett förslag som pekar bakåt.
Felet fanns före #11 (en version pick till en annan tag ger samma resultat), men med #11 blir tagbyten vanliga.
## Förväntat beteende
Ett förslag från pollern gäller den tag tjänsten följer. När tjänsten följer en annan tag ska `available_*` tömmas.
## Steg för att reproducera
1. En tjänst kör `repo:1.0.0`, och registryt får en ny digest under `1.0.0`. Efter en poll-cycle visas "Update available 1.0.0".
2. Deploya `repo:1.1.0` från versionslistan, eller med "Newer tag".
3. Efter jobbet och nästa poll-cycle visas fortfarande "Update available 1.0.0".
## Teknisk orsak
- `FinishJob` (`internal/master/store/jobs.go`) tömmer `available_*` bara när jobbets `to_ref`, utan `@digest`, är exakt lika med `available_ref`. Ett jobb till `repo:1.1.0` matchar aldrig `repo:1.0.0`.
- Pollern (`internal/master/poller/poller.go`, `suggest`) grupperar tjänsten under den nya taggen `repo:1.1.0`. Eftersom `ActualDigest == l.digest` returnerar den tidigt utan att skriva något, och det gamla `available_ref` rörs aldrig.
- Ingen annan kod tömmer `available_*`.
## Förslag till lösning
Låt pollern tömma ett **poll**-förslag (`available_source = 'poll'`) när `available_ref` inte är den ref tjänsten följer nu (`jobs.FollowedRef(actual_ref)`). Pollern skrev förslaget, så det är pollern som ska tömma det. Det fungerar oavsett hur tagbytet skedde: jobb, manuell `docker compose up` eller ändrad stackfil. `FinishJob` och reglerna för när den tömmer `available_*` lämnas orörda.
- Ny store-metod `ClearAvailable(id)`, eller `SetAvailable` med ett tomt värde. Den skriver bara vid ändring och publicerar `events.Services`.
- Gäller inte borttagna tjänster, tjänster som hoppas över av `SkipReason`, eller tjänster som följer en tag vars uppslag misslyckades i den här cycle.
- Test i `poller_test.go` och ett integrationstest i store.
## Öppen fråga
**Webhook-förslag** (`available_source = 'webhook'`) kan med avsikt peka på en annan tag än den tjänsten följer. CI kan till exempel säga "`1.28.0` finns" om en manuell tjänst som kör `1.27.3`. Då är förslaget inte inaktuellt utan själva poängen. Förslag: rör inte webhook-förslag i den här issuen. De töms redan av `FinishJob` när just den versionen deployas. Behöver de en egen regel, t.ex. "töm om tjänsten redan kör en tag som är lika med eller nyare än förslaget enligt `tagver`", blir det en separat issue.
## Scope
- Ingår: att pollern tömmer inaktuella poll-förslag, plus tester.
- Ingår inte: webhook-förslag, ändringar i `FinishJob`, `newer_*` (#11 hanterar det redan i pollern och när sidan visas).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Beskrivning
När en tjänst byter tag ligger det gamla "Update available" kvar för alltid. Exempel: en tjänst kör
gitea/gitea:1.27.3och pollern har registrerat en ny digest under1.27.3(available_ref = gitea/gitea:1.27.3). Du deployar sedan1.28.0, t.ex. via förslaget "Newer tag" från #11 eller via versionslistan. Tjänsten kör nu1.28.0, men chippet "Update available 1.27.3" står kvar i översikten, och auto-tjänster visar ett förslag som pekar bakåt.Felet fanns före #11 (en version pick till en annan tag ger samma resultat), men med #11 blir tagbyten vanliga.
Förväntat beteende
Ett förslag från pollern gäller den tag tjänsten följer. När tjänsten följer en annan tag ska
available_*tömmas.Steg för att reproducera
repo:1.0.0, och registryt får en ny digest under1.0.0. Efter en poll-cycle visas "Update available 1.0.0".repo:1.1.0från versionslistan, eller med "Newer tag".Teknisk orsak
FinishJob(internal/master/store/jobs.go) tömmeravailable_*bara när jobbetsto_ref, utan@digest, är exakt lika medavailable_ref. Ett jobb tillrepo:1.1.0matchar aldrigrepo:1.0.0.internal/master/poller/poller.go,suggest) grupperar tjänsten under den nya taggenrepo:1.1.0. EftersomActualDigest == l.digestreturnerar den tidigt utan att skriva något, och det gamlaavailable_refrörs aldrig.available_*.Förslag till lösning
Låt pollern tömma ett poll-förslag (
available_source = 'poll') näravailable_refinte är den ref tjänsten följer nu (jobs.FollowedRef(actual_ref)). Pollern skrev förslaget, så det är pollern som ska tömma det. Det fungerar oavsett hur tagbytet skedde: jobb, manuelldocker compose upeller ändrad stackfil.FinishJoboch reglerna för när den tömmeravailable_*lämnas orörda.ClearAvailable(id), ellerSetAvailablemed ett tomt värde. Den skriver bara vid ändring och publicerarevents.Services.SkipReason, eller tjänster som följer en tag vars uppslag misslyckades i den här cycle.poller_test.gooch ett integrationstest i store.Öppen fråga
Webhook-förslag (
available_source = 'webhook') kan med avsikt peka på en annan tag än den tjänsten följer. CI kan till exempel säga "1.28.0finns" om en manuell tjänst som kör1.27.3. Då är förslaget inte inaktuellt utan själva poängen. Förslag: rör inte webhook-förslag i den här issuen. De töms redan avFinishJobnär just den versionen deployas. Behöver de en egen regel, t.ex. "töm om tjänsten redan kör en tag som är lika med eller nyare än förslaget enligttagver", blir det en separat issue.Scope
FinishJob,newer_*(#11 hanterar det redan i pollern och när sidan visas).