-
Notifications
You must be signed in to change notification settings - Fork 101
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 GitHub Actions Maven CI #2
Conversation
Add continuous integration via GitHub's integrated actions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice.
By the way, I created a 'dev' branch from master this morning and changed the base of the other PR. The idea is to keep master for releases. What would be your take on that ?
There are definitely different schools of thought on this, but IMHO master should be the main development branch. On several projects I've created dev branches but ended up deleting them and moving development back to the master branch. One big reason is that we should be creating Git tags for each release, and in that case keeping master equal to the last release means that the master is redundant and always equal to the last tag. Additionally, you'll often have external developers clone the repo and start working on the master branch, not realizing that the issue they are working on has already been fixed in the dev branch. So it avoids a lot of questions and duplicated efforts if everything is normally just in master. You can of course create feature branches for new features, and then merge them back to master when that feature is done. |
I wished I'd have read this before sending the email to Google BUT what you say makes perfect sense so I'll delete dev right about now. I'll course correct in the email I'll send confirming I granted them access to the repo :) |
* Upgrade to Gradle 7.4 so that we can use the new `testReportAggregation`, which is a more standard way of aggregating test reports across all sub-projects. Use this opportunity to consolidate a bunch of test options into the root project for consistent configuration. * Comment tweak. * Restore code to make sure `copyRulesMarkdown` runs before test execution. * Make sure affected sources are in consistent sorted order for repeatable test execution. * Disable UI tests in headless environments. * Fix failing test on Windows due to line separators. * Attempt #2 to test correctly under Windows. * Consolidate Java compile options for consistency across projects. This will also help some tests pass on Windows environments. * Get another test passing on Windows.
…ityData#1382) * Upgrade to Gradle 7.4 so that we can use the new `testReportAggregation`, which is a more standard way of aggregating test reports across all sub-projects. Use this opportunity to consolidate a bunch of test options into the root project for consistent configuration. * Comment tweak. * Restore code to make sure `copyRulesMarkdown` runs before test execution. * Make sure affected sources are in consistent sorted order for repeatable test execution. * Disable UI tests in headless environments. * Fix failing test on Windows due to line separators. * Attempt MobilityData#2 to test correctly under Windows. * Consolidate Java compile options for consistency across projects. This will also help some tests pass on Windows environments. * Get another test passing on Windows.
Add continuous integration via GitHub's integrated actions.
It's currently configured using JDK 11. I believe we can add a matrix with other Java versions too.
We would have to pay for Travis CI because gtfs-validator is a private repo, so we'll see if this works as a free version 🙂.