-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Add initial continuous integration #3604
Conversation
Currently it will run phpunit, check coding standards and run phpstan. This can and should be build upon, so that eventually builds are automated and hopefully reproducable.
Thanks, this is very nice! 👍 Some comments and opinions from my side:
As for the whole thing about fixtures. I currently run the tests locally in conjunction with a script that generates a fresh database every time. It's what powers the demo site too; it generates new and up-to-date transactions daily. I used to ship a test database as well but the last time I did CI using Travis CI I downloaded a copy of the test database from Gitlab where it's hosted. I look forward to your input. I'm 100% sure there is no need for a full database. The Feature tests are old and manky, we can focus on API and Unit tests for now. As such I'm not a big fan of getting sucked into the GitHub sphere even further and I have a preference for Travis CI and things I could run locally. But there's little rocket science in these yaml files. I'll do a deepdive over the weekend and get back to you. Feel free to tinker with your PR and tell me what to do. There's a chance I'll copy your code and submit it myself to see what happens, step by step. But I'll reverse it all and merge to make sure you get the credits. Thanks again for your efforts! 🎉 |
SonarCloud Quality Gate failed. 205 Bugs No Coverage information |
Ah pardon me, will keep that in mind in the future.
Totally agree. In my mind the plan was to see what it comes back with, and then add whatever false positives to the ignore list, and then only fix we deemed important.
I guess the problem isn't necessary about you, it's for others committing. I personally see phpstorm's defaults as a good standard, but not everyone uses phpstorm. The alternative is that whoever maintains the code (which in this case is you) would have to go in and ensure standards are followed post merge.
Strange! I ran it locally, and it refused to run without the users. I just didn't have time to actually figure out the code to add the user. Maybe I overlooked something
Totally understand that, I'd be happy to change it to travis, or even circle (which officially supports running your configs locally). Lastly, the PR wasn't really ready. Was there a reason you merged? |
Yeah I wanted to see what would happen, and you didn't put it on draft status. Looking at GitHub feature set when it comes to actions, I'm not overly impressed I must say. My goal for this evening was to rejuvinate the Travis CI build |
Currently it will run phpunit, check coding standards and run
phpstan. This can and should be build upon, so that eventually builds
are automated and hopefully reproducible.
Furthermore, I've not been up to date with current community standards, nor
am I aware of any coding standards for Firefly, however, I have added coding
standards check on a whim in the hopes of opening a conversation, so I'm happy
to change to whatever is the best standards these days.
Lastly I added phpstan to improve code quality. There are lot of issues it's
returning (over 8000), though I'm not sure how valid they are. I've yet to
start to fix any issue.
I'm hoping in the future we can add additional automation to the whole
project so that the maintenance overheads of this project is reduced to a
minimum.
Lastly, I'm planning to as much of this as possible but this is going to be a
big task, so I'd very much appreciate your help as you understand the codebase
better. I think fixing the database fixtures should fix many, if not all tests.