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

Set up automated testing #640

Closed
5 tasks
danieliser opened this issue Feb 19, 2019 · 4 comments
Closed
5 tasks

Set up automated testing #640

danieliser opened this issue Feb 19, 2019 · 4 comments
Milestone

Comments

@danieliser
Copy link
Member

danieliser commented Feb 19, 2019

Now that we have PHPUnit set up and some integration tests created, we need these to be automatically run during pull requests, commits, merges, etc...

Merge these into something usable.

@danieliser danieliser added this to the v1.9 milestone Feb 19, 2019
@danieliser danieliser modified the milestones: v1.9, v1.10 Jan 14, 2020
@danieliser danieliser modified the milestones: v1.10, v1.11 Mar 26, 2020
@fpcorso fpcorso modified the milestones: v1.11, v1.12 Jun 5, 2020
@fpcorso fpcorso modified the milestones: v1.12, v1.13 Jun 10, 2020
@fpcorso fpcorso modified the milestones: v1.13, v1.14 Sep 30, 2020
@fpcorso fpcorso changed the title Set up automated testing with Travis-CI Set up automated testing Oct 27, 2020
@fpcorso
Copy link
Contributor

fpcorso commented Nov 5, 2020

@danieliser I did some research on this and we can definitely utilize GitHub Actions for this since our tests are rather straightforward. The question is: When should we run the tests? Just pushes on master and on PR's to master? Or, should we do PR's to develop too? Should we run the tests for each push to develop too?

@danieliser
Copy link
Member Author

@fpcorso I think this ideally should occur when a PR is submitted against develop, it prevents us from having to patch things in master. This way all new code must pass before merging.

Probably same for linting and other checks as well.

@fpcorso
Copy link
Contributor

fpcorso commented Nov 10, 2020

@danieliser I see two problems doing it only for PR's for develop:

  1. There are several smaller items that we commit directly to develop. Then, we branch off the release/x branch where we also commit to. So, when that goes to get merged into master it can contain quite a bit of code that wasn't in PR's for develop.
  2. What about hotfix/x branches? We branch those off of master and then merge back into master so those wouldn't get tested.

This is why I was thinking we should also do PR's to master as well.

@danieliser
Copy link
Member Author

@fpcorso My only concern with doing it off master might have been misplaced. For some reason I was thinking that would also pick up all the old code that is already malformatted, but it is probably only scanning the lines committed in the merge, otherwise thinking it through the branches merged into develop would also have that old/dirty code.

So I guess all merges into master & develop ?

fpcorso added a commit that referenced this issue Nov 17, 2020
Creates a new workflow that will validate composer, install
dependencies, and run PHPUnit tests.

Issue #640
fpcorso added a commit that referenced this issue Nov 17, 2020
@fpcorso fpcorso closed this as completed Nov 18, 2020
@fpcorso fpcorso mentioned this issue Dec 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants