You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Records SF request id to help find related events.
Drafting event metrics that are associated with the same NMT draft
generation request have a 'tags.draftGenerationRequestId' written to
them with an SF-specific id. This id is transferred around by
Activity.Current.Tags, by method arguments, and looked up by finding a
BuildProjectAsync event with a Serval build id.
When SMT is used, `null` is passed for draftGenerationRequestId method
arguments.
The frontend draft-jobs component considers event metrics using both
the older grouping logic as well as a new grouping system which uses
the draftGenerationRequestId to group events. The new system also
considers the BuildCompletedAsync event to be the finishing event for
a job.
A bug represented in the sample data was corrected to show the
incorrect behaviour of recording sf project id in the "userId" field,
rather than recording sf user id as a sf project id.
Copy file name to clipboardExpand all lines: .github/copilot-instructions.md
+11-4Lines changed: 11 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -42,7 +42,7 @@ This repository contains three interconnected applications:
42
42
43
43
- Write unit tests for new components and services
44
44
- Follow existing patterns for mocking dependencies
45
-
- Use TestEnvironment pattern from existing tests. Use the TestEnvironment class pattern rather than using a `beforeEach`.
45
+
- Use TestEnvironment pattern from existing tests. Use the TestEnvironment class pattern rather than using a `beforeEach`. Do not put helper functions outside of TestEnvironment classes; helper functions or setup functions should be in the TestEnvironment class.
46
46
- Test both online and offline scenarios
47
47
- Test permission boundaries
48
48
@@ -53,14 +53,20 @@ This repository contains three interconnected applications:
53
53
- Do not add method comments unless the method would be unclear to an experienced developer.
54
54
- Do put comments into the code to make it more clear what is going on if it would not be obvious to an experienced developer.
55
55
- Do put comments into the code if the intent is not clear from the code.
56
-
- All classes should have a comment to briefly explain why it is there and what its purpose is in the overall system, even if it seems obvious.
57
-
- Please do not fail to add a comment to any classes that are created. All classes should have a comment.
56
+
- All classes and interfaces should have a comment to briefly explain why it is there and what its purpose is in the overall system, even if it seems obvious.
57
+
- Please do not fail to add a comment to any classes or interfaces that are created. All classes and interfaces should have a comment.
58
58
59
59
# TypeScript language
60
60
61
61
- Use explicit true/false/null/undefined rather than truthy/falsy
62
62
- Never rely on JavaScript's truthy or falsy. Instead, work with actual true, false, null, and undefined values, rather than relying on their interpretation as truthy or falsy. For example, if `count` might be null, or undefined, or zero, don't write code like `if (count)` or `const foo:string = someVariable ? 'a' : 'b'`. Instead, inspect for the null, undefined, or zero rather than letting the value be interpreted as truthy for falsy. For example, use `if (count == null)` or `const foo:string = someVariable != null 'a' : 'b'` or `if (count > 0)`.
63
-
- Specify types where not obvious, such as when declaring variables and arguments, and for function return types.
63
+
- Specify types when declaring variables, arguments, and for function return types. For example, don't write
64
+
`const projectId = this.determineProjectId();` or
65
+
`const buildEvents = eventsSorted.filter(...);` or
- Although interacting with existing code and APIs may necessitate the use of `null`, when writing new code, prefer using `undefined` rather than `null`.
66
72
- Fields that are of type Subject or BehaviorSubject should have names that end with a `$`.
@@ -72,6 +78,7 @@ This repository contains three interconnected applications:
72
78
- It is better to write code that is verbose and understandable than terse and concise.
73
79
- It is better to explicitly check for and handle problems, or prevent problems from happening, than to assume problems will not happen.
74
80
- Corner-cases happen. They should be handled in code.
81
+
- Please don't change existing code without good justification. Existing code largely works and changing it will cause work for code review. Leave existing code as is when possible.
describe('associates older events into jobs',()=>{
149
+
// Older events did not have a draftGenerationRequestId and used another association method. They are stored in the sample events file and have an `A` in the various Ids used.
150
+
151
+
it('successful jobs',fakeAsync(()=>{
152
+
constenv=newTestEnvironment();
153
+
env.wait();
154
+
// The Serval build id and event metric ids are written here from looking at the sample data.
it('throws when there is a cancel event without a BuildCompleted cancel state',fakeAsync(()=>{
326
+
// When a cancel event happens, the current behavior is that the BuildCompletedAsync event also has a buildState of 'Canceled'. The createJobFromRequestGroup method will expect that.
it('skips request groups missing a start event',fakeAsync(()=>{
349
+
// Suppose the user selects a dante range such that the start date+time is after a draft generation starts and before it finishes. The list of event metrics will have events about the job being processed, but there will not be a start event. Omit those jobs from the data we present.
350
+
//
351
+
// If the end date falls after a start event and before a job's finish event, we'll just show that as in progress.
0 commit comments