-
Notifications
You must be signed in to change notification settings - Fork 21
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 some CI #21
Comments
Wonderful idea, it came up to me lately, too!
I would prefer GHActions, but merely because it is integrated with GH already. Other than that, I have no technical reasons.
Do you consider it more beneficiary to have the same compiler on all systems or to have the latest package manager-available compiler on particular systems? - I think setting up the latest stable compiler on all systems is way too time-costly as this is really a community project and should stay fun :-). What do you think?
I agree, FPC cannot do this. This sounds like an own task. I like the idea, but maybe we should put this to a task with lower priority. Maybe there could be a "warning test" (see next point).
I guess the tester program is a more solid choice. Another point to consider: Where do we store the test program or test programs. |
I played around with GHActions and, to my surprise, setting up jobs for MacOS and Windows turned out to be fairly simple.
Always using the same version has the benefit of having a well-known environment. Installing from a package manager, the version may change one day and suddenly the CI starts failing. Though I guess one could argue that from this project's perspective, we want to always be using the latest version, so if a package manager updates FPC and stuff breaks, we can react quickly.
Setting this up on Windows will probably be a bit tricky, but on Linux and MacOS we could just have a shell script sift through the compiler's output. There's the I agree that this could be added later, though.
I've never used it, so I can't really say. I don't think that creating a "proper" test suite has much sense; it seems to me that it'd be quicker and simpler to just have a bunch of small, basic programs that we compile and run - the test criteria being simply "it compiles successfully and doesn't crash when run". |
So,
Did I miss anything? Do you agree? |
Yes. 1) and 2) are already covered by the workflow I submitted in PR #25. 3) we can add later, once we sort out #22 and actually have a place to store test/example programs separately. As for 4), since we've settled on using GHActions, I've been thinking about looking into the Actions API and trying to create an Action myself - this would allow for using some GitHub-specific features, such as having errors/warning show up in the Pull Request web view, instead of requiring us to navigate to the CI run logs and skimming through them manually. But that's a project of its own and I'm a bit busy lately, so it'd probably be done no sooner than end of the month. |
Sounds great! Please let me know, what you think about my new proposal at #22 . |
I have created a GitHub Action for running FPC: https://github.com/marketplace/actions/free-pascal-compiler There's still a couple of minor issues I want to iron out, so I haven't slapped a |
This is great news and the Action looks beautiful. Can't wait to try it out with the pending PR. |
It would be useful to have Continuous Integration set up for the project, so we can check if PRs compile successfully. I have some experience with CircleCI and GitHub Actions, so I can handle setting this up. I'm opening this issue mostly to discuss the matter and ask some questions.
apt
/dnf
/brew
/chocolatey
?-Werror
option (i.e. treat warnings as errors). Do we want to try and figure out some solution for detecting warnings and marking the CI job as failed when they do?The text was updated successfully, but these errors were encountered: