This is the Final Blog post for Release 0.4 and also for this course. For this week, I was sick since last weekend. So, I could not work a lot.
For this week, I worked on reviewing the korean translation pull request and keep researching to edit the build log issue.
First the Korean translation pull request, I woke up in the morning and I received a message from the professor that a pull request for Korean translation is created. So, I went through a long reading about machine learning. Overall, I think the one who did the translation is native Korean. But there are some small mistakes in wording and the grammar was wrong. So, I made the comments on the issue to help the pull request creator fix the issue. Usually, he/she made mistakes on prepositional particles, which even native Korean people are making mistakes on it. So, the mistakes he/she made were understandable. And except that, the translation was great, very smooth.
I read some articles about machine learning and AI. Even though I was interested in it but it seemed like it needs a high-performance desktop to practice machine learning which I cannot work on because I only have a laptop that is not for high performance. But while I was reading the changes to review and make changes, I not only just create comments, but I also got some basic idea of changes in machine learning.
After that, I remember that I need to create the pull request for the commit that I made last week. But because I was sick this week, I could not work for a few days. So before I create a pull request, I tried to fetch the master branch of the telescope to my local branch to make it the newest version. However, It says that I cannot fetch because it has some conflict. Hence, I tried to find the part where it cause the problem. And I noticed that the git-stats.js, index.html, and build.html were gone which was surprised me because the three files are where I worked for the Dashboard and build log page menu unsynchronized issue.
This means what I fixed is gone and not needed anymore. Hence, I checked where it was from. And I found that while the Add handlebar engine issue was fixing, he also fixed my issue. So, I need to get rid of my commit because it is not needed anymore. And that was the reason why I couldn't fetch the upstream branch with the newest version. I did not feel good about this situation. But it was also my fault that I did not create a pull request last week. Hence from next time, I will create a pull request right away after I commit the changes.
And for the build log issue, this issue is that currently the build log is supporting now but it will be more useful if we save the previous build as cache and when there are more data added to the build, it will merge the previous build and current build and display the whole logs.
First, I need to understand the build log and how to write codes to create a log. For my fast understanding, I used sites in Korean to get information about logs. It helps me to understand the backend code of auto deployment and build.
This is what I understand from the code.
- With the exec function it will run the commands in the deploy.sh. In the deploy.sh, there is a long list of commands to build and print the log. And the return value from the exec function will save in the build.proc.
build.proc = shell.exec(
`./deploy.sh ${build.type} ${build.githubData.after}`,
{ silent: true },
(code) => {
build.finish(code);
builds.previous = builds.current;
builds.current = null;
// See if there's another build ready to go
run();
}
);
2.Merge the stdout and stderr of build proc and save it in the build.out
build.out = mergeStream(build.proc.stdout, build.proc.stderr);
3.Write the build logs stored in build.out.
const { out } = build;
onData = (data) => res.write(data);
out.on('data', onData);
4.Create router log to call the buildLogHandler function.
router.get('/log', buildLogHandler);
5.In the getBuildLog function, it will fetch the router log.
export const getBuildLog = async () => {
try {
const res = await fetch(autodeploymentUrl('log'));
if (!res.ok) {
if (res.status === 404) {
return null;
}
throw new Error('unable to get build log');
}
return res.body.getReader();
} catch (err) {
console.warn(err);
return null;
}
};
6.In the checkForBuild function, it will call the getBuildlog function
export default async function checkForBuild() {
// If we're already building, skip this check
if (build) {
return;
}
const status = await checkBuildStatus();
if (status.building) {
terminal.clear();
reader = await getBuildLog();
if (reader) {
// eslint-disable-next-line require-atomic-updates
build = { reader, title: status.title, startedAt: status.startedAt };
reader.read().then(processLog).catch(finish);
}
}
}
7.Finally, in build.js, it add an event listener to run the Checkforbuild function every 5 seconds.
import checkForBuild from '../build-log/check-for-build.js';
window.addEventListener('load', () => {
checkForBuild();
setInterval(checkForBuild, 5000);
});
This is How I understand the writing build log function. But I think it needs deeper research about the backend code.
And for saving the previous build log, I saw the previous variable on the builds object.
const builds = {
// Whatever built most recently
previous: null,
// Whatever we're building now
current: null,
// Whatever we're building next
pending: null,
};
I am trying to write code to save the previous build to the variable build.previous. So, it displays not only the current build but also the previous build.
To sum up, release 0.4 was a great experience to learn the concept of family issues. When I first time read release 0.4, my brain was blackout because it asked me to find the more difficult issues and one of the parts that I am struggling with was to search for the sufficient issue. for releases 0.2 and 0.3 I took more time to find an issue than editing the code. However, I saw the family issues are also acceptable which is consists of 2-3 small issues. And for this release 0.4, I worked on the reviewing pull request and worked on a total of 4 issues which are 3 small and 1 challenged issue. It was nice to experience learning more deeply about git and open-source projects.
This is the end of the 14 weeks of a long journey of my first open-source course. It was quite a long journey and takes lots of time compared to other courses. But it was a course I can work on without the pressure of exams and quizzes. That made me interested in this course.
Before I start this one, even someone asked me to work on the open-source project together to build a stronger resume. I rejected it because for me the open-source was something for professional developers. But after I learned git and the basics of open source, my thought on open source projects is changed that it is something everyone can contribute there are lots of issues created from beginner to difficult levels which need a high understanding of programming languages and servers. So, anyone with any level of programming language can contribute the open-source projects. I also enrolled in OSD700 to keep working on the open-source project. Because I am curious about what will be changed in my mind if I learn more about the open-source project.
If I can go back to the first day of the open-source course, I will tell myself that focus more on how to utilize the git. I think an open-source project is not possible to be done without knowledge about git and GitHub. Throughout this course, git was the hardest part for me because I was worried if I break the branch. So, I was very careful when I am practicing the git bash commands. However, now, I feel a bit more confident because I practiced more through the labs and assignments of this course. but still, I need to practice some more to be fully confident.
Top comments (0)