[#1407] DG: add Gradle instructions to workflow

[HCY123902]

Resolves #1407

Commit message:

Add gradle instructions for check style and back end testing 
in workflow

The original workflow does not specifically mention the
gradle commands to be executed for style checking and back
end testing.

Adding this information can help new developers to get started
more quickly.

Let's add the relevant gradle instructions to the Developer 
Guide.

[Tejas2805]

LGTM! One nit.

[Tejas2805]

Suggested change

	* **This project uses Checkstyle** to check the compliance of Java code. You can use [this document](https://se-education.org/guides/tutorials/checkstyle.html) to find how to use it. In Particular, run `gradlew checkstyleMain checkstyleTest checkstyleSystemtest` to check the style of all the relevant Java code.
	* **This project uses Checkstyle** to check the compliance of Java code. You can use [this document](https://se-education.org/guides/tutorials/checkstyle.html) to find how to use it. In particular, run `gradlew checkstyleMain checkstyleTest checkstyleSystemtest` to check the style of all the relevant Java code.

[HCY123902]

Thanks for pointing it out. I have edited it.

[fzdy1914]

@dcshzj Any idea why the deployment is failing here?

[dcshzj]

@dcshzj Any idea why the deployment is failing here?

The deployment code itself works, but I think the issue was that there were multiple instances of it running. The surge.sh deployment cannot perfectly pinpoint the exact workflow run to download the artifacts for.

One way is to not trigger too many CI runs within a short time frame. If deployment fails again, we can just trigger it again by closing and reopening the PR.

[fzdy1914]

@dcshzj Any idea why the deployment is failing here?

The deployment code itself works, but I think the issue was that there were multiple instances of it running. The surge.sh deployment cannot perfectly pinpoint the exact workflow run to download the artifacts for.

One way is to not trigger too many CI runs within a short time frame. If deployment fails again, we can just trigger it again by closing and reopening the PR.

Can you try to look into a fix for it? As it is affecting our normal usage.

Instead of uploading artifacts into one position. Is modifying the path or name helping, different repo have a different paths?

Just look into it first.

[fzdy1914]

@dcshzj Any idea why the deployment is failing here?

The deployment code itself works, but I think the issue was that there were multiple instances of it running. The surge.sh deployment cannot perfectly pinpoint the exact workflow run to download the artifacts for.
One way is to not trigger too many CI runs within a short time frame. If deployment fails again, we can just trigger it again by closing and reopening the PR.

Can you try to look into a fix for it? As it is affecting our normal usage.

Instead of uploading artifacts into one position. Is modifying the path or name helping, different repo have a different paths?

Just look into it first.

@dcshzj And since I will be merging this PR, you may open an issue to keep the discussion.