Fix coverage link, streamline env vars in CI

[ggetz]

Description

TLDR; This PR should fix the link to coverage results in GitHub PRs, but more broadly, does some housekeeping of our deploy and status scripts.

Mismatched environment variables

Between incremental updates and migrating between various services and tools, our build and deploy scripts have become quite sprawling. Some things also fall through the cracks, like the broken test coverage link in the CI checks, but we're also dragging along patterns that are no longer serving us. This PR does not fix everything, but attempts to consolidate and cleanup some of these CI/CD related things.

I noticed when reviewing #12957 that there are several misconfigured environment variables in the dev workflow as opposed to the deploy workflow where most other build artifacts are uploaded. Mis-matches across the workflows were ultimately resulting in broken links.

• When using the pull_request hook, the GitHub ref_name is different than the branch name. This ended up using different versions of "DEPLOYED_URL" leading to a broken link.
• A similar issue arises when trying to use the commit SHA for operations like setting statuses. In pull_request triggers, the value of COMMIT_SHA will the merge commit.

Change summary

• Does not change the production or dedicated sandcastle deployment workflows beyond removing redundant env properties.
• Cleaned up some (quite old) deploy scripts:
  • Moved the setDeployStatus script out of gulpfile.js as it is unrelated to the build processes—It is now a standalone node script with command line help docs.
  • Replaced with setCommitStatus. For flexibility, the command itself is more granular so it can be run per-artifact and per-status update. This allows check updates to run separately in different tasks or workflows as needed.
  • Removed the deploySetVersion script out of gulpfile.js in favor of the npm version cli command which we use for our release processes.
  • Since they are generally only the concerns of the maintainers, these script have been removed from package.json and the corresponding build guide.
• Moved the coverage job to it's own workflow, having it only run on pull requests triggers. This simplifies the job a lot and, to my knowledge, the check itself isn't super helpful until a PR is opened.
• Created .env files in which can configure common environment variables as described in the updated docs of ContinuousIntegration/README.md
  • This adds a dependency on dotenvx as it allows us to variable expansion and simple command substitution.
  • Defines values accounting for variations in environments:
    • In CI, the trigger can be either push or pull_request. Since pull_request does not run in the context of the branch itself, we need to account for the available GitHub context to grab branch names and commit SHA's.
    • Locally, fall back to git commands to allow for development testing.
  • Create a new env var, CESIUM_VERSION, that detects the current package version making it more convenient to access across various contexts.

Issue number and link

Fixes #11827

Testing plan

1. When CI runs, all expected jobs should start:

2. CI artifacts should then show up as pending:

3. CI artifacts should all transition to success and each link should work:
   a. "coverage results" should navigate to the coverage results index
   b. "cesium-.tgz" should download the packed npm package
   c. "Cesium-.zip" should download the release zip
   d. "index.html` should navigate to the deployed static build

Author checklist

• I have submitted a Contributor License Agreement
• I have added my name to CONTRIBUTORS.md
• I have updated CHANGES.md with a short summary of my change
• I have added or updated unit tests to ensure consistent code coverage
• I have updated the inline documentation, and included code examples where relevant
• I have performed a self-review of my code

[github-actions]

Thank you for the pull request, @ggetz!

✅ We can confirm we have a CLA on file for you.

[ggetz]

Wait to review; This needs an additional change.

[ggetz]

This is ready for review and the PR description is up-to-date.

[jjspace]

Overall very nice, thanks @ggetz! Definitely much better and more robust than the quick change I recently made. Just had one comment that's really a question

CI seems to be passing and working as expected. I assume there's not really any way to test this locally?

[jjspace]

Why are we calling dotenvx from npx instead of using it directly in the script files? is it just so we can specify the extra .env.pull_request files?

Also as an aside for my curiosity, what is the reason you went with dotenvx instead of just dotenv? a quick search seems that the motivation would be to encrypt the env files with secrets but we aren't doing that. Is this future proofing?

[ggetz]

I chose dotenvx specifically because it supports variable expansion and command substitution, which I don't believe "regular" dotenv supports.

[ggetz]

Why are we calling dotenvx from npx instead of using it directly in the script files? is it just so we can specify the extra .env.pull_request files?

Yes. The default .env is being loaded from the script itself, but this command is what allows us to override with the CI-specific values in .env.pull_request. If there's an alternative syntax you know of, please tell!

[jjspace]

Suggested change

	--delete'
	--delete

(I believe this is extra/a typo?)

[ggetz]

I don't think so—This should be the closing single quote paired with line 58.

[jjspace]

Ah I see now... that's deceptively hard to see 🕵️ A consequence of needing to use sh -c I guess. I also found the extra -- really hard to connect to the npx command at first but might just have to deal with it 🤷

[ggetz]

CI seems to be passing and working as expected. I assume there's not really any way to test this locally?

No, not end-to-end. You could test some commands locally, but if CI is working as expected I think that's unnecessary.