harbor: Wrong image pull times and tag retention removing not correct images

Yes. (Sorry I missed this.) Scanning should not update pull time. We should consider adding “Last scan time” field if enough people think it is useful.

After discussion, we decided to implement it in this way

1. Add a configuration “Skip Scanner Pull Update”, if Harbor admin checks it, the scanner will not update the pull time for scanner, neither the pull count.
2. The “Last Scan Time”, because it only indicates the last time pulled by the scanner, but it can not indicate the scan success or failure, it seems this time is of no use in the UI. usually, the Harbor user will check the scan report and get the scan time in it, it is the accurate scan time user wants to know. So we will not add the “Last Scan Time” column in the artifact table.
3. In order to discriminate the scanner robot account from user created robot account, we add a UUID in the scanner robot account, it is a UUID generated by installation and the scanner robot account is named like that: robot$<projectName>+<Scanner UUID (8byte)>-<Scanner Name>-<UUID> and the Harbor detect the scanner robot account by prefix robot$<projectName>+<Scanner UUID (8byte)>

we’re consider not update pull time when doing scanning, or add some extra fields to distinguish the user pull from scan pull

@qnetter should we consider to fix it?

I agree that pulls from clients is what matters. That is why I suggest distinguishing between last PULLED time and last SCANNED time (which should not update last pulled time). If there were an indicator with last scanned time of S(uccessful)/U(successful)/-(could not scan) that would be good too.

I think you are using scan images, which is updating pull time. @wy65701436 @heww is it possible not to update pull time when just doing scanning

We will find a solution to fix this issue in harbor 2.5.0. cc @xaleeks

@wy65701436 thanks for working on this 👍🏼

I want to comment on what you mentioned here:

Before moving forward, I would like to point out that this is not actually a bug fix, but a change in behavior that we should be aware of and decide if it is good to go.

I see your point there, however I think it’s important to distinguish pull operations performed against Harbor from actual external clients that consume the artifacts, versus pulls that are performed by an internal system component.

when considering retention policies (for example), we generally care about the consumption (i.e. pulls) of the images from a perspective of Harbor consumers, not consumption (pulls) made by internal tooling of Harbor itself that fulfils some other function (such as periodically scanning the images)

if folks enable SCAN_ALL job, retention policies becomes useless and I’m not sure that was ever the intent, right? so, I would agree that this may not be considered a pure bug, however it does negatively interacts with another functionality that becomes unusable as a result of current behaviour.

in any case, just wanted to share my 2 cents and happy to see the team is going to address this!