parent
bc018f8b39
commit
98f0ebde8b
76 changed files with 5966 additions and 4 deletions
@ -0,0 +1,173 @@ |
||||
const fs = require('fs'); |
||||
const path = require('path'); |
||||
|
||||
const OPEN_AI_API_KEY = process.env.OPEN_AI_API_KEY; |
||||
const ALL_BEST_PRACTICES_DIR = path.join( |
||||
__dirname, |
||||
'../src/data/best-practices' |
||||
); |
||||
const BEST_PRACTICE_JSON_DIR = path.join( |
||||
__dirname, |
||||
'../public/jsons/best-practices' |
||||
); |
||||
|
||||
const bestPracticeId = process.argv[2]; |
||||
const bestPracticeTitle = bestPracticeId.replace(/-/g, ' '); |
||||
|
||||
const allowedBestPracticeIds = fs.readdirSync(ALL_BEST_PRACTICES_DIR); |
||||
if (!bestPracticeId) { |
||||
console.error('bestPracticeId is required'); |
||||
process.exit(1); |
||||
} |
||||
|
||||
if (!allowedBestPracticeIds.includes(bestPracticeId)) { |
||||
console.error(`Invalid bestPractice key ${bestPracticeId}`); |
||||
console.error(`Allowed keys are ${allowedBestPracticeIds.join(', ')}`); |
||||
process.exit(1); |
||||
} |
||||
|
||||
const BEST_PRACTICE_CONTENT_DIR = path.join( |
||||
ALL_BEST_PRACTICES_DIR, |
||||
bestPracticeId, |
||||
'content' |
||||
); |
||||
const { Configuration, OpenAIApi } = require('openai'); |
||||
const configuration = new Configuration({ |
||||
apiKey: OPEN_AI_API_KEY, |
||||
}); |
||||
|
||||
const openai = new OpenAIApi(configuration); |
||||
|
||||
function getFilesInFolder(folderPath, fileList = {}) { |
||||
const files = fs.readdirSync(folderPath); |
||||
|
||||
files.forEach((file) => { |
||||
const filePath = path.join(folderPath, file); |
||||
const stats = fs.statSync(filePath); |
||||
|
||||
if (stats.isDirectory()) { |
||||
getFilesInFolder(filePath, fileList); |
||||
} else if (stats.isFile()) { |
||||
const fileUrl = filePath |
||||
.replace(BEST_PRACTICE_CONTENT_DIR, '') // Remove the content folder |
||||
.replace(/\/\d+-/g, '/') // Remove ordering info `/101-ecosystem` |
||||
.replace(/\/index\.md$/, '') // Make the `/index.md` to become the parent folder only |
||||
.replace(/\.md$/, ''); // Remove `.md` from the end of file |
||||
|
||||
fileList[fileUrl] = filePath; |
||||
} |
||||
}); |
||||
|
||||
return fileList; |
||||
} |
||||
|
||||
function writeTopicContent(topicTitle) { |
||||
let prompt = `I am reading best-practices about "${bestPracticeTitle}". I want to know more about "${parentTopic}". Why is it important? Content should be in markdown. Behave as if you are the author of the best practices.`; |
||||
|
||||
console.log(`Generating '${topicTitle || parentTopic}'...`); |
||||
|
||||
return new Promise((resolve, reject) => { |
||||
openai |
||||
.createChatCompletion({ |
||||
model: 'gpt-4', |
||||
messages: [ |
||||
{ |
||||
role: 'user', |
||||
content: prompt, |
||||
}, |
||||
], |
||||
}) |
||||
.then((response) => { |
||||
const article = response.data.choices[0].message.content; |
||||
|
||||
resolve(article); |
||||
}) |
||||
.catch((err) => { |
||||
reject(err); |
||||
}); |
||||
}); |
||||
} |
||||
|
||||
async function writeFileForGroup(group, topicUrlToPathMapping) { |
||||
const topicId = group?.properties?.controlName; |
||||
const topicTitle = group?.children?.controls?.control?.find( |
||||
(control) => control?.typeID === 'Label' |
||||
)?.properties?.text; |
||||
const currTopicUrl = `/${topicId}`; |
||||
if (currTopicUrl.startsWith('/check:')) { |
||||
return; |
||||
} |
||||
|
||||
const contentFilePath = topicUrlToPathMapping[currTopicUrl]; |
||||
|
||||
if (!contentFilePath) { |
||||
console.log(`Missing file for: ${currTopicUrl}`); |
||||
process.exit(0); |
||||
return; |
||||
} |
||||
|
||||
const currentFileContent = fs.readFileSync(contentFilePath, 'utf8'); |
||||
const isFileEmpty = currentFileContent.replace(/^#.+/, ``).trim() === ''; |
||||
|
||||
if (!isFileEmpty) { |
||||
console.log(`Ignoring ${topicId}. Not empty.`); |
||||
return; |
||||
} |
||||
|
||||
let newFileContent = `# ${topicTitle}`; |
||||
|
||||
if (!OPEN_AI_API_KEY) { |
||||
console.log(`Writing ${topicId}..`); |
||||
|
||||
fs.writeFileSync(contentFilePath, newFileContent, 'utf8'); |
||||
return; |
||||
} |
||||
|
||||
const topicContent = await writeTopicContent(topicTitle); |
||||
newFileContent += `\n\n${topicContent}`; |
||||
|
||||
console.log(`Writing ${topicId}..`); |
||||
fs.writeFileSync(contentFilePath, newFileContent, 'utf8'); |
||||
|
||||
// console.log(currentFileContent); |
||||
// console.log(currTopicUrl); |
||||
// console.log(topicTitle); |
||||
// console.log(topicUrlToPathMapping[currTopicUrl]); |
||||
} |
||||
|
||||
async function run() { |
||||
const topicUrlToPathMapping = getFilesInFolder(BEST_PRACTICE_CONTENT_DIR); |
||||
|
||||
const bestPracticeJson = require(path.join( |
||||
BEST_PRACTICE_JSON_DIR, |
||||
`${bestPracticeId}.json` |
||||
)); |
||||
const groups = bestPracticeJson?.mockup?.controls?.control?.filter( |
||||
(control) => |
||||
control.typeID === '__group__' && |
||||
!control.properties?.controlName?.startsWith('ext_link') |
||||
); |
||||
|
||||
if (!OPEN_AI_API_KEY) { |
||||
console.log('----------------------------------------'); |
||||
console.log('OPEN_AI_API_KEY not found. Skipping openai api calls...'); |
||||
console.log('----------------------------------------'); |
||||
} |
||||
|
||||
const writePromises = []; |
||||
for (let group of groups) { |
||||
writePromises.push(writeFileForGroup(group, topicUrlToPathMapping)); |
||||
} |
||||
|
||||
console.log('Waiting for all files to be written...'); |
||||
await Promise.all(writePromises); |
||||
} |
||||
|
||||
run() |
||||
.then(() => { |
||||
console.log('Done'); |
||||
}) |
||||
.catch((err) => { |
||||
console.error(err); |
||||
process.exit(1); |
||||
}); |
File diff suppressed because one or more lines are too long
@ -0,0 +1 @@ |
||||
# Address any questions or concerns that the author may have. |
@ -0,0 +1 @@ |
||||
# Address all the feedback received, including any concerns or questions raised. |
@ -0,0 +1 @@ |
||||
# Provide adequate time for code reviews and ensure that it is a priority. |
@ -0,0 +1 @@ |
||||
# Double-check that the code adheres to the project's coding standards and best practices. |
@ -0,0 +1 @@ |
||||
# Ensure that you understand the codebase and its architecture. |
@ -0,0 +1 @@ |
||||
# Be open to feedback from the author and be willing to make adjustments to your feedback if necessary. |
@ -0,0 +1 @@ |
||||
# Celebrate the successful completion of the code change! |
@ -0,0 +1 @@ |
||||
# Verify that the code change is functioning as expected in the production environment. |
@ -0,0 +1 @@ |
||||
# Ensure that the changes are complete and ready for review, including all necessary tests and documentation. |
@ -0,0 +1 @@ |
||||
# Provide clear and actionable feedback, including specific suggestions for improvement and explanations of any concerns. |
@ -0,0 +1 @@ |
||||
# Ensure that the code change adheres to the project's coding standards and best practices. |
@ -0,0 +1 @@ |
||||
# Ensure that the purpose of code reviews is clear to everyone. |
@ -0,0 +1 @@ |
||||
# Be willing to collaborate with the author to resolve any issues or concerns that arise during the review process. |
@ -0,0 +1 @@ |
||||
# Break down complex tasks into smaller easily manageable PRs. |
@ -0,0 +1 @@ |
||||
# Define a process for conflict resolution in code reviews. |
@ -0,0 +1 @@ |
||||
# Stay consistent with the overall project design and architecture. |
@ -0,0 +1 @@ |
||||
# Seek continuous improvement, not perfection. |
@ -0,0 +1 @@ |
||||
# Encourage reviewing code in unknown-areas for cross-functional knowledge. |
@ -0,0 +1 @@ |
||||
# Ensure that “Definition of Done” is documented and clear to everyone |
@ -0,0 +1 @@ |
||||
# Determine the appropriate level of review needed based on the scope and impact of the code change. |
@ -0,0 +1 @@ |
||||
# Write the documentation for the feature or changes if required. |
@ -0,0 +1 @@ |
||||
# Document and standardize the code review process. |
@ -0,0 +1 @@ |
||||
# Encourage team members to participate in code reviews. |
@ -0,0 +1 @@ |
||||
# Write a failing test if the change is for a bug fix. |
@ -0,0 +1 @@ |
||||
# Follow the coding standards and any other team guidelines. |
@ -0,0 +1 @@ |
||||
# Consider the impact of the change on other parts of the system. |
@ -0,0 +1 @@ |
||||
# Implement the suggested changes and provide explanations where needed. |
@ -0,0 +1 @@ |
||||
# |
@ -0,0 +1 @@ |
||||
# Use code reviews as an opportunity for knowledge sharing and learning. |
@ -0,0 +1 @@ |
||||
# Understand the requirements and the context in which change was made. |
@ -0,0 +1 @@ |
||||
# Make list of any potential risks or issues that could arise with the change. |
@ -0,0 +1 @@ |
||||
# Merge the approved code change into the main/feature branch. |
@ -0,0 +1 @@ |
||||
# Monitor the performance and functionality of the code change and address any issues that arise. |
@ -0,0 +1 @@ |
||||
# Constantly monitor and improve code review process. |
@ -0,0 +1 @@ |
||||
# Leave comments to suggest improvements, but prefix it with "Nit" if it's not critical to meeting the standards |
@ -0,0 +1 @@ |
||||
# Encourage communication/collaboration; avoid treating code reviews as a one-way process. |
@ -0,0 +1 @@ |
||||
# Take notes on any questions or concerns about the change to discuss them during the review. |
@ -0,0 +1 @@ |
||||
# Approach the review process with an open mind, and be willing to learn from and collaborate with other team members. |
@ -0,0 +1 @@ |
||||
# Approach the process with an open mind; be willing to provide constructive feedback and collaborate to improve code quality |
@ -0,0 +1 @@ |
||||
# Consider using pair programming as an alternative or supplement to code reviews. |
@ -0,0 +1 @@ |
||||
# Provide positive feedback in addition to constructive criticism, to reinforce good practices and boost team morale. |
@ -0,0 +1 @@ |
||||
# Identify any potential performance, security, or scalability concerns and note them for discussion during the review. |
@ -0,0 +1 @@ |
||||
# Identify any potential performance, security, or scalability concerns, and discuss them with the author. |
@ -0,0 +1 @@ |
||||
# Based on the requirements, prepare a list of items that should have been covered in the changes. |
@ -0,0 +1 @@ |
||||
# Prioritize your feedback, focusing on the most important issues first. |
@ -0,0 +1 @@ |
||||
# Be respectful and professional in your feedback, avoiding personal attacks or derogatory comments. |
@ -0,0 +1 @@ |
||||
# Make sure to add proper title, description, any screenshots, relevant links, configuration changes etc in the PR. |
@ -0,0 +1 @@ |
||||
# Consider the overall quality of the code, including readability, maintainability, and scalability. |
@ -0,0 +1 @@ |
||||
# Run the tests again and ensure that they all pass. |
@ -0,0 +1 @@ |
||||
# Recognition and rewards for those with track record of quality feedback. |
@ -0,0 +1 @@ |
||||
# Resolve conflicting opinions in a timely manner; don't let a PR sit around due to disagreement. |
@ -0,0 +1 @@ |
||||
# Review any documentation or design specifications related to the change. |
@ -0,0 +1 @@ |
||||
# Ensure that the relevant documentation has been updated. |
@ -0,0 +1 @@ |
||||
# Review any tests included with the code change to verify that they adequately cover the functionality and edge cases. |
@ -0,0 +1 @@ |
||||
# Review the updated code and ensure that the suggested changes have been implemented as expected. |
@ -0,0 +1 @@ |
||||
# Run the tests and ensure that they all pass after making changes |
@ -0,0 +1 @@ |
||||
# Encourage authors to seek feedback during development before submitting a formal code review. |
@ -0,0 +1 @@ |
||||
# Seek feedback from other team members if you are unsure about the changes. |
@ -0,0 +1 @@ |
||||
# Review your code before submitting for review. |
@ -0,0 +1 @@ |
||||
# Set clear expectations for code review turnaround times. |
@ -0,0 +1 @@ |
||||
# Keep the short-term and long-term considerations in mind. |
@ -0,0 +1 @@ |
||||
# Have a definitive style guide for style preferences. |
@ -0,0 +1 @@ |
||||
# Submit the updated code for a second review if needed. |
@ -0,0 +1 @@ |
||||
# Team wide styleguide is the absolute authority styling. Verify changes against those instead of personal preferences |
@ -0,0 +1 @@ |
||||
# Verify that the code change has been properly tested in a development environment. |
@ -0,0 +1 @@ |
||||
# Hold regular code review sessions to discuss broader trends or issues that arise during the review process. |
@ -0,0 +1 @@ |
||||
# Update any documentation that may have made obsolete through the changes. |
@ -0,0 +1 @@ |
||||
# Update any documentation or code comments affected by the changes. |
@ -0,0 +1 @@ |
||||
# Use automation to speed up the code reviews (linting, sniffing etc) |
@ -0,0 +1 @@ |
||||
# Verify that all the feedback has been addressed by the author. |
@ -0,0 +1 @@ |
||||
# Write the automated tests. |
Loading…
Reference in new issue