-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automate component version badges #2656
base: main
Are you sure you want to change the base?
Conversation
using `gray-matter` to manage the front matter read/write and formatting
running `yarn run generate-component-changelog-entries`
The latest updates on your projects. Learn more about Vercel for Git βοΈ
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Just left a couple questions and I think one thing to change.
@@ -1,14 +1,22 @@ | |||
--- | |||
title: Badge | |||
description: Concise, non-interactive labels that represent metadata. | |||
caption: Concise, non-interactive labels that represent metadata. | |||
description: 'Concise, non-interactive labels that represent metadata.' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: why do these caption and description have quotes? it seems like most of the others dont.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the deployed site (https://hds-website-git-alex-ju-automate-component-ver-2d7be8-hashicorp.vercel.app/components/badge) seems like it doesn't randomly add the quotes to the page so I guess its fine
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to the schema used by js-yaml
strings over a certain length are moved to a block (hence the >-
notation) and the short ones get wrapped in single quotes to avoid parse errors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -1,13 +1,18 @@ | |||
--- | |||
title: Card | |||
description: A block container that provides styling for elevation, border, and background. | |||
caption: A block container that provides styling for elevation, border, and background. | |||
description: 'A block container that provides styling for elevation, border, and background.' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same question about the quotes here.
@@ -1,19 +1,24 @@ | |||
--- | |||
title: Table | |||
description: Used to display organized, two-dimensional tabular data. | |||
caption: Used to display organized, two-dimensional tabular data. | |||
description: 'Used to display organized, two-dimensional tabular data.' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another example where the quotes are randomly added.
const indexPath = `${allComponentsPath[componentName]}/index.md`; | ||
|
||
if (fs.existsSync(indexPath)) { | ||
// Fetch the index markdown file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really appreciate the comments!
}); | ||
}; | ||
|
||
const cleanComponentFrontMatter = (components) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: I think version needs to be added to the args here? Otherwise I don't see where it is defined.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right, yes, I believe I'm missing the second argument here β will update!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed in 15e50a9 thanks for spotting this!
parsedFrontMatter.data.status = {}; | ||
} | ||
if ( | ||
parsedFrontMatter.data.status.added !== version && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: going forward, will we still need to manually add the added
tag?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
indeed. either add it manually, or change it from Updated to Added where needed. We can try to add some logic there to distinguish additions from updates, but it's not going to be a clean cut and wasn't sure it's worth the effort.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense! We add stuff much less often.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything working great! Tested it with a few different scenarios and all worked out. Just one comment I left.
parsedFrontMatter.data.status.added !== version && | ||
parsedFrontMatter.data.status.updated !== version | ||
) { | ||
parsedFrontMatter.data.status.updated = version; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Suggestion] This would defiantly make the implementation more complicated π , and is probably best raised in the doc, but for patch releases do we want to remove all "updated" badges from a previous minor release?
Just thinking of the situation where we do a minor release, the badges get added, and then we have some need to do a patch release quickly after and the badges get removed before consumers are really even aware they were there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point. Let me think about it, maybe we can prevent this from code rather than docs π€
π Summary
Follow-up on #2613 to automate the removal and addition of version badges for each component.
π οΈ Detailed description
gray-matter
(a slim wrapper ofjs-yaml
) to read/write the front matter we updated components' front matter to match the standard schemaOutcome
Running the automated script revealed a few instances where the 4.15 badge was missing. Any
added
orupdated
badge before 4.15 is removed.Note
This PR will be updated to match the agreed proposal outlined by @zamoore in the release cycle RFC.
Limitations
The script doesn't generate
added
ordeprecated
badges (onlyupdated
). When you add a new component (or deprecate one), you have to either update the front matter status when updating the associated docs or change the badge type after running the automated script. These details will be covered in the confluence documentation updates.π External links
Jira ticket: HDS-4299
π¬ Please consider using conventional comments when reviewing this PR.