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