CE-2799: Differentiate tags with different icon in JobTable
A new component called JobGitRefIcon has been created to represent the type of the git reference. The type of the reference is fetched asynchronously from the backend (using the Git.gitReferenceType
endpoint), and based on this, an appropriate icon is displayed:
-
CommitIcon
if the reference type is aCOMMIT
-
LabelOutlinedIcon
if the reference type is aTAG
-
QuestionMarkIcon
if the reference type isUNKNOWN
Closes CE-2798
Merge request reports
Activity
requested review from @christinajenks, @anderslindh1, @imretoth, @johannaszepanski, and @skybrewer
assigned to @domonkosgulyas
- Resolved by Christina Jenks
My updates in the latest commit: the long commit SHA didn't fit next to the icon, so I rearranged the log table a bit. Also, I replaced the loading skeleton variant for the icon.
Currently, the icons load approximately simultaneously with the reference. Would it be better to have a pre-defined skeleton for both the icon and the reference link components and only display them when both have loaded?
Maybe we could add a Tooltip describing what the "?" specifically means since in retrospect it's not obvious
I don't think we can TBH... We don't expect to run into it, and even we don't know what it would mean. :)
Do we care about the padding on the left of the icon?
I'd say so yeah. And that's probably easier to address as part of this MR than having to create a JIRA task, refine it, plan it, etc.
reset approvals from @christinajenks by pushing to the branch
- Edited by Christina Jenks
13 13 revision: string 14 14 }; 15 15 16 export default function GitRefLink({ url, revision, ...props }) { 16 export default function GitRefLink({ 17 url, 18 revision, 19 displayReference, The naming of this prop confused me because at first I thought it was a boolean.
But then I looked a bit more into this and had a few suggestions:
- Could we do this change in common-ui? We already have a GitRefLink component there
- To make this consistent with how the ExternalLink component works, could we consider making it take children instead? Then the logic could be "if children are present, use them; otherwise use the revision". Alternatively if you think it's clearer to have separate props like you do now, maybe call the displayReference prop something different (maybe "linkContent" or similar)
Edited by Christina Jenks
- src/components/Job/JobTable/JobGitRefIcon.js 0 → 100644
12 () => ({ 13 project_id: job?.gitProjectId, 14 git_reference: job?.gitReference 15 }), 16 [job] 17 ); 18 19 const { value: referenceTypeResponse } = useAPIMethod({ 20 fcn: client.apis.Git.gitReferenceType, 21 params: params 22 }); 23 24 if (!referenceTypeResponse) { 25 return ( 26 <Skeleton 27 sx={{ marginLeft: "4px" }}