fixes #477 (Build should not rely on git)

[satti-hari-krishna-reddy]

fixes #477

Description :

This pull request addresses the issue where the build process was relying on Git for version information. The problem arose when the build process did not have Git available.

Changes Made :

-In package.json, updated the version field to the latest released GitHub version

-In build.ts, modified the code to use the version specified in package.json.

[satti-hari-krishna-reddy]

@sushain97 could you please review my changes? Your feedback would be highly appreciated.

[sushain97]

Seems reasonable - some questions below.

[sushain97]

Can you update the version field above to actually match the latest released GH version if we're going to use it as the canonical source?

[sushain97]

Why do environment variables need to be manually passed through? As far as I'm aware, yarn doesn't modify them from the caller.

[coveralls]

Pull Request Test Coverage Report for Build 7208461184

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 97.64%

---

Totals
Change from base Build 7013115272:	0.0%
Covered Lines:	1380
Relevant Lines:	1395

---

💛 - Coveralls

[satti-hari-krishna-reddy]

@sushain97 sorry for late reply college work has been busy, Sure, I'll update the version in package.json field to actually match the latest released git hub version but i got a doubt , Since we're moving away from direct reliance on Git ,will manual updates to package.json be required for every release?

[TinoDidriksen]

...will manual updates to package.json be required for every release?

Yes. That is the point. It's about what the source of truth is, and I hold that it should be the code - GitHub is merely storage, and must not be an integral part of the project.

[sushain97]

Since we're moving away from direct reliance on Git ,will manual updates to package.json be required for every release?

Yes, this is fine. Ideally, we set up a GH workflow to create a tag and it'll fail when the tag already exists and succeed when a commit is pushed to master with a new tag.

[sushain97]

Yes. That is the point. It's about what the source of truth is, and I hold that it should be the code - GitHub is merely storage, and must not be an integral part of the project.

I don't disagree with this but I'd argue GitHub isn't relevant here. The tags are a Git construct which is arguably part of the source of truth. The point that a build shouldn't require .git is one I agree with though so this is fine in general.

[satti-hari-krishna-reddy]

Hey @sushain97 , @TinoDidriksen , I've made some changes to the code. Can you take a look and let me know if everything's good now? Thanks!

[sushain97]

@satti-hari-krishna-reddy CI is failing.

[satti-hari-krishna-reddy]

@sushain97 , I've got the Prettier error fixed, so the CI should be good to go now!