UI: Freight Image-Tags hardly readable after with long tag names

[MPritsch]

Checklist

• [x] I've searched the issue queue to verify this is not a duplicate bug report.
• [x] I've included steps to reproduce the bug.
• [x] I've pasted the output of kargo version.

Description

When using longer image-tag names, the selectable freights do not display the image-tag name properly. I know that there has to be some kind of limitation to the size, but if the freight was configurable to scale with the tag-name it would help us a lot. I'm open to suggestions on how this could be mitigated.

Currently we fetch the versions of our maven pom.xml and add a release-candidate tag to iterate over it. That means we also get the typical SNAPSHOT suffix from maven. With this version we tag our images and karge watches for the tag structure. E.g. 0.6.1-SNAPSHOT-rc1

With more time these names will get longer and be even harder to read in the small freight view. You could try with a 1234.5678.9123-SNAPSHOT-rc1234 Version and see what happens.

I'm not sure if this feature-requests already covers it? https://github.com/akuity/kargo/issues/1430

And I think this pull-request might already change the behaviour, although I know not much about frontends https://github.com/akuity/kargo/pull/1510

Screenshots

Here are the boxes like they list the image-tags now. Currently there is no way to differentiate 0.6.1-SNAPSHOT-rc1 from 0.6.1-rc2 in the freight-view besides scrolling down on each box:

When selecting a single freight it is a bit better, since the field is bigger, but still not great.

Steps to Reproduce

Create a few freights with long tag names. E.g.

apiVersion: kargo.akuity.io/v1alpha1
kind: Freight
commits:
  - id: b61ad0a3b216bbe9efd66207d3274cfbfaee261d
    message: 'fix: commit message'
    repoURL: >-
      https://gitlab.com/path/to/my/repo
images:
  - digest: sha256:98ae8a8009441ade8b96bb6f9356430bd89ae142c4260988e5b925d35a9c18b3
    repoURL: >-
      https://gitlab.com/path/to/my/repo/image
    tag: 0.6.0-SNAPSHOT-rc1
---
apiVersion: kargo.akuity.io/v1alpha1
kind: Freight
commits:
  - id: b61ad0a3b216bbe9efd66207d3274cfbfaee261d
    message: 'fix: commit message'
    repoURL: >-
      https://gitlab.com/path/to/my/repo
images:
  - digest: sha256:98ae8a8009441ade8b96bb6f9356430bd89ae142c4260988e5b925d35a9c18b3
    repoURL: >-
      https://gitlab.com/path/to/my/repo/image
    tag: 0.6.0-SNAPSHOT-rc2
---
apiVersion: kargo.akuity.io/v1alpha1
kind: Freight
commits:
  - id: b61ad0a3b216bbe9efd66207d3274cfbfaee261d
    message: 'fix: commit message'
    repoURL: >-
      https://gitlab.com/path/to/my/repo
images:
  - digest: sha256:98ae8a8009441ade8b96bb6f9356430bd89ae142c4260988e5b925d35a9c18b3
    repoURL: >-
      https://gitlab.com/path/to/my/repo/image
    tag: 0.6.1-SNAPSHOT-rc3

Version

kargo is from the wolfi packages here: https://github.com/wolfi-dev/os/blob/df0bb04cb3c656d7181bbceb660cec5aa6d087f1/kargo.yaml So the output of "kargo version" is just go build meta-information:

{
  "Version": "devel+07d91a1.dirty",
  "BuildDate": "1970-01-01T00:00:00Z",
  "GitCommit": "07d91a10f3d082ebcb22585f25dae16abd510709",
  "GitTreeDirty": true,
  "GoVersion": "go1.22.0",
  "Compiler": "gc",
  "Platform": "linux/amd64"
}

Just use version 0.4.0 from your own repository or install the wolfi version in a wolfi-base image via apk update && apk add kargo-0.4.0-r0

[krancour]

I leave it to @rbreeze to continue exploring how to deal with this sort of issue. I think we can all agree that it's always challenging to cram lots of information into small bits of real estate.

Without being dismissive of the problem -- because it is a problem -- I can suggest something that might help you a little bit in the interim.

You're probably aware that Freight aliases can be edited. My suggestion is to identify Freight that is of specific interest and update the alias to something semantically meaningful but short. Identifying important freight by its alias is likely to be a more pleasant experience than working off of image tag names.

Even if image tag names happened to be short, the above strategy can be useful. You might have many Freight that pair the same image version with different versions of config. Or you might have many Freight that pair many versions of an image with the same version of config. Since a Freight's ID and alias identify the specific combination of all the artifacts contained within the Freight, it's probably a more reliable way for humans to track a piece of Freight that is of specific interest.

[MPritsch]

Hey, thanks for the quick response. You are right, it is more important to identify what version we currently want to deploy, rather than the exact image-tag.

Before going in with the alias solution, might I suggest implementing an alternative display mode? Similiar to chats, where you can select to read the content "compact" or "full". This would allow the box to scale according to the contents in the "full" mode, but be truncated in the "compact" mode.

Now for the alias: I read that aliases can be edited, although it looked like a manual process in the UI or using the kargo-cli. That might be editable from our pipeline, but the process is not optimal. Currently it works like this:

CI creates image with the tag -> kargo periodically checks for new images with regex -> we need to edit the alias

Since we don't know when kargo is done creating the freight, we would need to trigger the alias change delayed and hope it is there. I'm not sure how I would filter for that Freight, although I assume it can be done with the cli.

Or is there a automatic way to rename every alias according to a template? Like <image-tag>-<optional-random-word>. Last part if it would be a duplicate otherwise, in case the image-tag has multiple associated git-hashs. Since I have not yet edited aliases, I'm also unsure if longer names would be displayed correctly.

EDIT: Have been thinking about it for a minute. The alias solution would be even more beneficial, since it would also display the proper version in the graph below. Would love some kind of automatic renaming mechanism though.

[github-actions[bot]]

This issue has been automatically marked as stale because it had no activity for 90 days. It will be closed if no activity occurs in the next 30 days but can be reopened if it becomes relevant again.

[krancour]

@rbreeze do you know if this is still an issue?