Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[#10874] Finalize Migration to Github Actions #10905

Merged
merged 14 commits into from
Feb 7, 2021

Conversation

rrtheonlyone
Copy link
Contributor

@rrtheonlyone rrtheonlyone commented Jan 1, 2021

Part of #10874

  • Updated build.gradle:
    • remove temporary file directory change in CI for jvm (not sure why this was done earlier)
    • file deletion was not done earlier in CI environment - I left it as is
  • Updated documentation to mention Github Actions and added status badge to README
  • Removed Travis related files
  • Split to 2 workflow files for component and E2E tests

@teammates-bot
Copy link

Hi @rrtheonlyone, these parts of your pull request do not appear to follow our contributing guidelines:

  1. PR Title
    • Issue Reference (#<issue-number>) missing.

@rrtheonlyone rrtheonlyone changed the title Finalize Migration to Github Actions [#10874] Finalize Migration to Github Actions Jan 1, 2021
@wkurniawan07
Copy link
Member

Remove Appveyor as well?

@wkurniawan07
Copy link
Member

wkurniawan07 commented Jan 2, 2021

We should separate main workflow into E2E and component tests

It actually makes more sense to separate into back-end, front-end, and E2E. It fits our paradigm of separation between back-end and front-end better.

Add: although, it might not work for Codecov. If it really doesn't perhaps we should keep the status quo or use multiple code coverage services.

@madanalogy
Copy link
Contributor

I know coveralls supports merging different code coverage reports (used it recently for a project) but not sure about codecov. Maybe take a look at https://docs.codecov.io/docs/merging-reports

@wkurniawan07
Copy link
Member

Now that I think about it again, if we do go down the separate back end and front end workflow, then the coverage report needs to be separate as well otherwise it defeats the purpose. Of course, that's an if.

@rrtheonlyone
Copy link
Contributor Author

So just to double check, our current options are:

  1. Keep it as is so we have one coverage report and one build status (build status is tagged to workflow) to show in README. However, we lose the ability to restart specific tests like E2E tests. We have to restart the entire workflow.

  2. Split into backend/frontend/E2E workflos and have multiple status badges. Also find some way to handle codecov for the separate runs (either through https://docs.codecov.io/docs/flags or https://docs.codecov.io/docs/merging-reports). This will however, allow us to rerun groups of tests without running everything again.

@wkurniawan07
Copy link
Member

  1. Keep it as is so we have one coverage report and one build status (build status is tagged to workflow) to show in README.

Not really, keeping to status quo is never a considered option. It's either split to E2E + everything else (one coverage report, up to two build statuses) or split to BE/FE/E2E (two coverage reports, up to three build statuses). And as I mentioned before, if we do split BE/FE, it's more logical to also split the coverage reports.

@madanalogy madanalogy added the s.Ongoing The PR is being worked on by the author(s) label Jan 8, 2021
@rrtheonlyone
Copy link
Contributor Author

Okay for now went with option (1) above. One coverage report + 2 build status:

Screenshot 2021-01-10 at 12 43 35 AM

@damithc do we want to set it up such that on any change made to release branch, we run the E2E tests on multiple browsers and os? It is a simple change to do as well.

@damithc
Copy link
Contributor

damithc commented Jan 9, 2021

@damithc do we want to set it up such that on any change made to release branch, we run the E2E tests on multiple browsers and os? It is a simple change to do as well.

We know production servers are Unix, so perhaps no need to run on other OS? Testing on multiple browsers might be nice to have. We can try it for a while to see how it goes, if you don't see any downsides. Are the tests equally stable on different browsers?

@wkurniawan07
Copy link
Member

wkurniawan07 commented Jan 10, 2021

We know production servers are Unix, so perhaps no need to run on other OS?

This reasoning is not accurate. E2E goes beyond just testing back-end; the front-end should be tested and is very much dependent on user (which means it is virtually limitless).

In fact, if we follow that line of reasoning, it is the back-end test that needs not be done on non-Unix. We still do it anyway because the cost is very low (and also to cater to Windows-based devs). But probably we should do it only on pushes to master and release to save some time/resources.

Speaking of cross-browser and cross-OS test, this is where services like Saucelabs will be useful for us. Probably it's about time to finish up #9597 for good.

@damithc
Copy link
Contributor

damithc commented Jan 10, 2021

This reasoning is not accurate. E2E goes beyond just testing back-end; the front-end should be tested and is very much dependent on user (which means it is virtually limitless).

Oh right, I forgot that part.

@rrtheonlyone
Copy link
Contributor Author

rrtheonlyone commented Jan 10, 2021

Okay guess we retain this for now.

We run component tests + linting on windows/ubuntu and only run E2E on firefox/ubuntu at the moment. We can play around with more options in future.

I can create a separate PR to add in multiple browsers + OS when we push to release branch. Last time when I checked chrome browser tests did fail more often.

Ready for review

@rrtheonlyone rrtheonlyone added s.ToReview The PR is waiting for review(s) and removed s.Ongoing The PR is being worked on by the author(s) labels Jan 10, 2021
Copy link
Member

@wkurniawan07 wkurniawan07 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, do one last round of check that there is no more mention of "Travis" or "Appveyor" in the repo.

README.md Outdated Show resolved Hide resolved
docs/development.md Outdated Show resolved Hide resolved
.github/workflows/component.yml Show resolved Hide resolved
docs/process.md Outdated
@@ -173,12 +173,12 @@ Their full descriptions can be viewed under the [labels page](https://github.com
#### Code review

Your code will be reviewed, in this sequence, by:
* Travis CI: by running static analysis.<br>
* Github Actions: by running static analysis.<br>
If there are problems found, the build will terminate without proceeding to testing.<br>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this line is accurate anymore; it was in V6

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup removed

docs/process.md Show resolved Hide resolved
@wkurniawan07 wkurniawan07 added s.Ongoing The PR is being worked on by the author(s) and removed s.ToReview The PR is waiting for review(s) labels Jan 18, 2021
Copy link
Member

@wkurniawan07 wkurniawan07 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor comments added. Almost there.

@@ -223,8 +223,10 @@ There are several files used to configure various aspects of the system.
* `gradle.properties`, `gradle-wrapper.properties`: Contains the Gradle and Gradle wrapper configuration.
* `package.json`: Contains the front-end third-party dependencies specification, as well as configurations for automated tasks/routines to be run via NPM.
* `angular.json`: Contains the Angular application configuration.
* `.travis.yml`: Contains the Travis CI job configuration.
* `appveyor.yml`: Contains the AppVeyor CI job configuration.
* `component.yml`: GitHub Action configuration for component tests run on every pull request/push to master or release branch.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"run on every push to master or release branch" is an additional detail that needs not be mentioned here. It also necessitates more places to be changed if we ever decide to change the practice.

docs/process.md Show resolved Hide resolved
- name: Start App Engine
run: ./gradlew appengineStart
- name: Start Tests
run: ./gradlew lnpTests
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently this will not pass in GitHub Actions without also incorporating the fixes from fb8177c.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I see, okay updated based on the commit

Copy link
Member

@wkurniawan07 wkurniawan07 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@rrtheonlyone rrtheonlyone added s.ToMerge The PR is approved by all reviewers including final reviewer; ready for merging and removed s.Ongoing The PR is being worked on by the author(s) labels Feb 7, 2021
@rrtheonlyone rrtheonlyone merged commit c4ba7a0 into TEAMMATES:master Feb 7, 2021
@rrtheonlyone rrtheonlyone deleted the finalize-migration branch February 7, 2021 17:08
@madanalogy madanalogy added this to the V7.10.0 milestone Feb 8, 2021
@madanalogy madanalogy added the c.DevOps Process-related or build-related improvement and addition label Feb 8, 2021
@madanalogy madanalogy removed their request for review February 8, 2021 03:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c.DevOps Process-related or build-related improvement and addition s.ToMerge The PR is approved by all reviewers including final reviewer; ready for merging
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants