Automate v8 source upgrade

[GustavoCaso]

Related to #165

This PR adds two new workflows: upgrade and automatic build v8 binaries for macOS and Linux.

The upgrade workflow is triggered every first day of the month, and the automatic v8 build gets trigger on every pull_request which branch follows the v8_<version>_upgrade pattern.

The upgrade workflow runs every day and check the current stable v8 version with the currently installed version on the repo.

For that, I created a v8_version file inside the deps folder and a python script to check the versions. If the versions are the same the script returns 1 stopping the workflow from continuing.

This would allow us to have a more robust upgrade flow.

Until we figured out how to fully automate the Windows build the new automatic build v8 workflow only takes care of building the binaries for macOS and Linux. Example build that failed for Windows.

@genevieve @rogchap @dylanahsmith Please me know what you think.

[codecov]

Codecov Report

Merging #181 (256a7c7) into master (6dff945) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #181   +/-   ##
=======================================
  Coverage   95.59%   95.59%           
=======================================
  Files          16       16           
  Lines         545      545           
=======================================
  Hits          521      521           
  Misses         15       15           
  Partials        9        9           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6dff945...256a7c7. Read the comment docs.

[GustavoCaso]

@rogchap would you be able to have a look? Thanks 😄

[rogchap]

Stable releases are on average every 4 weeks. Running every day seems excessive, but I guess most of the time it will just be a version check.

[dylanahsmith]

Roughly every 4 weeks a new major Stable release is done.

(Source: https://v8.dev/docs/release-process#stable-releases)

Emphasis on "major" was mine, they more frequently release patch version bumps.

Currently, https://omahaproxy.appspot.com shows the most recent version bump was only about a week apart:

• current_reldate: 09/30/21
• previous_reldate: 09/24/21

If we tracked the branch head for the stable channel (currently branch-heads/9.4) then that would make the changes even more frequent. Releasing fixes that frequently might be overkill, but automating the preparation work for getting a security fix out would be useful.

[genevieve]

We can start with every day and if it gets noisy (which it shouldn't if it's largely version checks and silent exiting if releases are more like once a week), we can reduce the frequency.

[dylanahsmith]

The v8 source will already be checked out as a git submodule, so I'm not sure if this step is relevant anymore. Also, if it were used, it would be used from deps_path, otherwise it would create another v8 checkout directory under v8_path which we don't want.

For existing git checkouts, gclient sync would be used to fetch the dependencies, as is done in deps/build.py. Actually, I think the only reason why we might want to do that here is to update the depot_tools commit that is being used. Otherwise, this script is just using the v8 git checkout (to copy the include headers).

[GustavoCaso]

@genevieve Thanks for 🟢, but I'm experimenting with my own fork and there are some things that need to be addressed to be able to merge into master. Give me a little more time and I will let you know when is a good time to merge it

[GustavoCaso]

@rogchap @dylanahsmith @genevieve I've done some explorations on my fork and this is the conclusion I was able to gether.

• The new workflow v8upgrade.yml works as expected
• The branch created by the workflow won't trigger any flows neither the build not the test ones. This is not an issue but rather a design from the GitHub actions docs

If you would like to trigger a workflow from a workflow run, you can trigger the event using a personal access token. You'll need to create a personal access token and store it as a secret. To minimize your GitHub Actions usage costs, ensure that you don't create recursive or unintended workflow runs. For more information on storing a personal access token as a secret, see "Creating and storing encrypted secrets."

• I tested on my fork by creating a PAT and it worked, but with the problem that the test workflow would also be triggered. This is unfortunate because they would always fail and it is a waste of time.
  Possible solution: Would be to create a new base branch maybe v8_upgrades and make sure that the test workflow is not triggered on pull request or push which the target is that branch.

Since these changes I believe are out of the scope of this PR, I think we can merge this one to start getting the benefits of the upgrade workflow and in the future, we can try improving it.
Also, once this hits master I'm happy to continue working on improving the workflow.

[GustavoCaso]

I validated that PR created with the v8upgrade workflow will not be overwrite by scheduled runs.

In the case the workflows runs for the latest version and it takes some time to make the necessary changes for the different distributions, the workflow will be trigger everyday but since the changes to the PR are identical the workflow will exit successfully. You can see an example on my fork actions https://github.com/GustavoCaso/v8go/actions/workflows/v8upgrade.yml

[dylanahsmith]

A couple of minor suggestions, otherwise, LGTM

[dylanahsmith]

Suggested change

	1) Because the build is so long, this is not automatically triggered. Go to the [V8
	1) The build is not yet triggered automatically. To trigger it manually, go to the [V8

[dylanahsmith]

nitpick: I think mentioning that it is a version file would make the code clearer

Suggested change

	def read_v8_file(src_path):
	def read_v8_version_file(src_path):

same for update_v8_file