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
Show workflow jobs and steps #152
Conversation
d9d07f5
to
ab8171c
Compare
ab8171c
to
cff5cf5
Compare
src/utils/timeUtils.ts
Outdated
* **NOTE:** If the difference between `start` and `end` is negative, `end` will be treated as the current time. | ||
*/ | ||
// tslint:disable-next-line: export-name | ||
export function getTimeElapsedString(start: Date, end: Date): string { |
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.
I think you can probably replace this with this https://momentjs.com/docs/#/displaying/difference/
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.
I can't see any way to cleanly format a moment object to 2m 31s
.
It seems like it's a missing feature that people have wanted for a while and is still not implemented in moment: moment/moment#463
I've looked at both
And neither can do the job.
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.
IMO it feels like you're trying to pack too much info into the description. This piece feels the least important relative to it's code complexity and I would get rid of it.
src/utils/timeUtils.ts
Outdated
* **NOTE:** If the difference between `start` and `end` is negative, `end` will be treated as the current time. | ||
*/ | ||
// tslint:disable-next-line: export-name | ||
export function getTimeElapsedString(start: Date, end: Date): string { |
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.
IMO it feels like you're trying to pack too much info into the description. This piece feels the least important relative to it's code complexity and I would get rid of it.
src/constants.ts
Outdated
|
||
// Doc for these parameter values: https://developer.github.com/v3/checks/runs/#parameters | ||
|
||
export enum Conclusion { |
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.
These types should stay in the same file as the type for GitHubAction
since they're so closely related. If you don't like having it in ActionTreeItem
, make a separate file for GitHub stuff. The separate file would somewhat represent a drop-in replacement for the GitHub npm package that I assume you guys will switch to soon
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.
I think you missed this comment-- we probably could move this to the gitHubTypings. Annoying that they don't have their own enum for this, but alas
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.
Oops! Will do.
src/tree/JobTreeItem.ts
Outdated
public get description(): string { | ||
if (this.data.conclusion !== null) { | ||
const elapsedMs: number = this.completedDate.getTime() - this.startedDate.getTime(); | ||
return `${convertConclusionToVerb(<Conclusion>this.data.conclusion)} ${moment(this.completedDate).fromNow()} in ${prettyMs(elapsedMs)}`; |
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.
So I wanted to confirm with GitHub, but apparently it doesn't support any language other than English: https://github.blog/2010-07-13-github-in-your-language/
I feel like we might want to localize this string because I'm not sure this format is standard in say, Chinese or something.
Actually, moment is writing complete phrases like 21 days ago or 21 minutes ago, so I'm not sure how we would localize that unless moment has language support.
src/tree/JobTreeItem.ts
Outdated
public get description(): string { | ||
if (this.data.conclusion !== null) { | ||
const elapsedMs: number = this.completedDate.getTime() - this.startedDate.getTime(); | ||
return `${convertConclusionToVerb(<Conclusion>this.data.conclusion)} ${moment(this.completedDate).fromNow()} in ${prettyMs(elapsedMs)}`; |
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.
Rather than casting this.data.conclusion, you could make a get property for conclusion that confirms it's one of the enums and then returns it casted.
https://stackoverflow.com/questions/43804805/check-if-value-exists-in-enum-in-typescript
EDIT: Sorry, I know you asked me offline but I hadn't thought of that at the time 😅
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.
So in the getter, if it's not in the enum should I throw an error?
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.
Yeah, probably something along the lines of "Received unexpected conclusion." I'm pretty sure it'll mess up the getActionIconPath code anyway if we don't (since the path won't be found if it's not an enum we expect.)
src/tree/JobTreeItem.ts
Outdated
public get description(): string { | ||
if (this.data.conclusion !== null) { | ||
const elapsedMs: number = this.completedDate.getTime() - this.startedDate.getTime(); | ||
return `${convertConclusionToVerb(this.conclusion)} ${moment(this.completedDate).fromNow()} in ${prettyMs(elapsedMs)}`; |
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.
Actually, moment is writing complete phrases like 21 days ago or 21 minutes ago, so I'm not sure how we would localize that unless moment has language support.
Moment supports localization. However, I don't think "pretty-ms" does. Even if it did - my original comment was that you're putting too much stuff in the description and I stand by that. The biggest reason I love VS Code is because of how lightweight/simple it is - and I want our extensions to reflect that. Pick only the most important information to display and throw the rest in a "View Properties" command
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.
I say we at least keep how long ago it ran (i.e. 4 days ago). I don't know if we need the verbs (like completed for instance) in there since that's kind of the point of icons (though I'm pretty sure that's not accessible, so I dunno).
I personally like the descriptions, and to your point about being lightweight/simple, while I agree, this level of description only appears if they drill down pretty far into the Actions node, in which case I feel like the user would be trying to get more detailed information about the steps.
The data object (the GitHub response type) doesn't include the times in a human friendly format (they just have completed/started timestamps) so I see some value in displaying that in a easily read manner.
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.
I'm fine with how long ago it ran and the conclusion/status (because the icons aren't accessible, as you mentioned). The conclusion/status is most important (gotta know if it worked) and how long ago is second most important (if it ran a month ago, I might need to update my site). I just don't see as much value in the elapsed time - why do I care if it took a minute or an hour?
this level of description only appears if they drill down pretty far into the Actions node, in which case I feel like the user would be trying to get more detailed information about the steps.
so if it looks gross already - we're allowed to make it even more gross? It's not that far down :P
The data object (the GitHub response type) doesn't include the times in a human friendly format (they just have completed/started timestamps) so I see some value in displaying that in a easily read manner.
Doesn't mean you have to display it in the description. There's no reason the "properties" object we display has to be the exact object we get from GitHub. We can modify and make it look better as much as we want (still needs to be localizable, though - and out of scope for this PR).
…ticwebapps into alex/workflowJobs
💯 |
Not sure how Nathan's commits got on this PR, but if that's an issue I will try to fix it.
A lot of added code here is added to deal with displaying the times and date completed of the jobs and steps. We might try to rely on an npm package to do this for us, however I didn't immediately find one that suited our needs.
I also feel that I need to write tests for the util functions I added. I will write these soon I just wanted to get eyes on the code asap.