Skip to content
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.

Sign up for GitHub

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

feat: added support to set version dynamically based on the release #30

Merged
merged 5 commits into from
May 24, 2024
Merged

feat: added support to set version dynamically based on the release #30

Changes from 2 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
220a56d
feat: added support to set version dynamically based on the release
abdullahwaheed May 22, 2024
769691f
feat: added defaults for each datadog env based values
abdullahwaheed May 22, 2024
d06b234
refactor: updated logic of version datadog flag to be used from config
abdullahwaheed May 23, 2024
76f18ed
refactor: added check for not initializing DD if not confiuration pro…
abdullahwaheed May 24, 2024
f05ff2a
refactor: removed defaults for applicationId and clientToken
abdullahwaheed May 24, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 24 additions & 11 deletions src/DatadogLoggingService.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,14 +27,26 @@
this.initialize();
adamstankiewicz marked this conversation as resolved.
Show resolved Hide resolved
}

initialize() {
async initialize() {
let datadogVersion = process.env.DATADOG_VERSION || '1.0.0';
try {
const response = await fetch('version.json');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[curious] Were any alternatives to fetching version.json considered yet? I'm a bit concerned needing to fetch version.json at runtime as it's a network request users will need to resolve before the MFE is initialized/executed. While it wouldn't be an expensive network request to make, it still introduces a request waterfall where version.json needs to be fetched before DataDog and the rest of the MFE can be initialized.

For example, an alternative could be to modify the tubular scripts regarding FrontendBuilder to create a new, generic APP_VERSION environment variable passed to the npm run build similar to the environment variables defined in the app config. Then, the change for DatadogLoggingService would be to consume this new environment variable created/passed in tubular instead of introducing a network request to get the same data.

If we opted for this alternative approach, the only change for DatadogLoggingService would be updating the environment variable used from process.env.DATADOG_VERSION to the generic APP_VERSION; I don't think we'd want to hardcode DATADOG_VERSION in tubular per se, hence the suggestion of a generically named APP_VERSION instead).

See this diff for what the alternative tubular approach might look like to mitigate the need to fetch version.json. With those changes, when we iterate over app_config.items() to generate a list of environment variables to use with npm run build, APP_VERSION would also be passed where DatadogLoggingService could then access it.

If you still wanted the ability for consumers to override the version for DataDog, then DatadogLoggingService could do something like:

const datadogVersion = process.env.DATADOG_VERSION || process.env.APP_VERSION || '1.0.0';

...where a custom DATADOG_VERSION takes precedence over the generic APP_VERSION.

Curious to hear what you think about this alternative approach, primarily to not need to fetch the version.json file since that introduces a minor request waterfall that could impact frontend performance.

if (response.ok) {
const data = await response.json();
if (data?.commit) {
datadogVersion = data.commit;
}
}
} catch (error) {
console.error('Version File Not Found');

Check warning on line 41 in src/DatadogLoggingService.js

View workflow job for this annotation

GitHub Actions / tests 

Unexpected console statement
}
datadogRum.init({
applicationId: process.env.DATADOG_APPLICATION_ID,
clientToken: process.env.DATADOG_CLIENT_TOKEN,
site: process.env.DATADOG_SITE,
service: process.env.DATADOG_SERVICE,
env: process.env.DATADOG_ENV,
version: process.env.DATADOG_VERSION,
applicationId: process.env.DATADOG_APPLICATION_ID || '',
adamstankiewicz marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: given the required config settings check is implemented above, the applicationId and clientToken properties probably don't need to fallback to an empty string since they should be expected to have a value at this point.

The other fallbacks to empty strings for the other properties still makes sense, though :)

clientToken: process.env.DATADOG_CLIENT_TOKEN || '',
site: process.env.DATADOG_SITE || '',
service: process.env.DATADOG_SERVICE || '',
env: process.env.DATADOG_ENV || '',
version: datadogVersion,
sessionSampleRate: parseInt(process.env.DATADOG_SESSION_SAMPLE_RATE || 0, 10),
sessionReplaySampleRate: parseInt(process.env.DATADOG_SESSION_REPLAY_SAMPLE_RATE || 0, 10),
trackUserInteractions: true,
Expand All @@ -43,12 +55,13 @@
defaultPrivacyLevel: 'mask-user-input',
});
datadogLogs.init({
clientToken: process.env.DATADOG_CLIENT_TOKEN,
site: process.env.DATADOG_SITE,
env: process.env.DATADOG_ENV,
clientToken: process.env.DATADOG_CLIENT_TOKEN || '',
site: process.env.DATADOG_SITE || '',
env: process.env.DATADOG_ENV || '',
forwardErrorsToLogs: true,
sessionSampleRate: parseInt(process.env.DATADOG_LOGS_SESSION_SAMPLE_RATE || 0, 10),
service: process.env.DATADOG_SERVICE,
service: process.env.DATADOG_SERVICE || '',
version: datadogVersion,
});
}

Expand Down
Loading