apple
Use GitHub Actions for checks
Hello everyone ✌️
this PR might fix #152 and therefore also contributes to #225.
Two reasons why this would be a step forward:
- Forks can simply check in their own repo if something isn't broken. Right now they have to check stuff locally and we all know this might not happen all the time 😅
- PRs, depending on the setting, can run automatically run checks without an approval.
- Since this is the "start" of using GitHub actions, we can also start implemeting #225 as dependabot would also run on actions and we can create workflows that "do something after they run" or after "dependabot created a PR"... See https://docs.github.com/en/code-security/dependabot/working-with-dependabot/automating-dependabot-with-github-actions
- ???
I just converted the checks from the circleci config for now because
- I wanted to hear your opinion about this first (generally)
- What do you think about using my pkl-gha project 🙃
- Other comments 🙃 Le me know if this is "fine" or if I also convert all the other jobs. On the other side we can also do this as follow-ups in other PRs. Let me know what you prefer.
Because using a matrix is super easy to setup on actions, I also decided to run jdk 21 on windows 🤷 This isn't in the circleci config but doesn't hurt i guess?!
If you want to see how this looks like in action, checkout this run on my fork:
TODO before merge:
- [ ] Remove demosntrate github action run
Hi @StefMa, thanks for the PR!
We're considering switching to GitHub Actions, but we're not quite ready yet to accept a commit for this. However, you can always maintain this commit on your own fork for now as a way to build and test Pkl yourself.
However, this is quite useful for us (I've never used GHA before), so, let's keep this PR around so we can go from here when we're ready!
Also, I'm open to using pkl-gha :)
@bioball Actions are currently disabled on the repo, but would it be useful to merge anyway so that other folks who are forking can run the tests? I wouldn't want this to turn into a maintenance burden for the team to have untested code in the repo, but it could also be a nice quality of life improvement for contributors.
In case it helps forks in the meantime, here are some workflows that I've used to test PRs before submitting them to Pkl upstream.
The build summary shows how jobs are arranged, with Gradle and Native Image build reports, and so on. The workflows use StepSecurity's actions to harden execution (disables sudo access and offers firewalling to protect from supply chain attacks). Actions use principle-of-least-privilege and pin to specific commits for each step.
I'd be glad to offer these upstream if the project is interested, or on this PR, but I suspect the Pkl project authors will want to render these configs with Pkl, as is done for Circle
let's keep this PR around so we can go from here when we're ready!
Sure, take your time. This is going to nowhere 🙃
Also, I'm open to using pkl-gha :)
Nice to hear! If you have any feedback to it, let me know.
I tend to agree with @madrob.
You can simply disable Actions in the repo settings.
Could be quite easy enabled and improved by the community over time, while you still exploring GH Actions.. 🤔
On the other side, it of course require a bit of maintainance...
@sgammon nice, thanks for sharing that! I initially started with just PRs to give the maintainers here an first glimps/overview about this and gather feedback. With that approach we can move slowly away from CircleCI to GH Actions and don't put anything at once here and addiotnally some other "nice|good-to-have" actions. Lets start with the pure basics and we can iterate from here.