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 Maven Toolchains Declaration (#276) #282
Conversation
I would very much appreciate if @dmitry-shibanov or someone else from the maintainers could chime in here and tell me what I have to do in order to get this merged. Thanks in advance. |
cc32ecf
to
6206324
Compare
6206324
to
0758be1
Compare
@dmitry-shibanov can you help here? That would be very helpful! |
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.
This is a great feature and would simplify setup for maven based builds!
0758be1
to
c7f4d58
Compare
@marko-zivic-93 can you maybe review/ merge this? |
c7f4d58
to
ca4cb14
Compare
The failing validation checks were caused by connection timeouts during installation. Not by anything in this PR. |
@Okeanos could you point us to a sample workflow run that uses the new functionality? That would help me understand what we're adding here. I saw the YAML snippet you added for the docs, but I'm also curious how the toolchain gets consumed in later steps. |
You can take a look here: https://github.com/eclipse-platform/eclipse.platform/blob/master/.github/workflows/build.yml currently we maintain a hand written toolchains.xml and need to pass that to the maven command see: with an automatic one like proposed here, it would be just a matter of calling |
ca4cb14
to
16eadc0
Compare
@brcrista I setup a minimal project with pipelines that are hopefully self-descriptive here: https://github.com/Okeanos/setup-java-example/actions It appears that Gradle benefits less from this PR on GitHub Actions than anticipated from Gradle#14903 even for e.g. Gradle 7.3 which did not support Maven Toolchains detection. Some jobs, such as the Java 8 and 11 are supposed to fail (technically, even for Gradle but it has auto-detection that works on GitHub Actions and for some reason matrix builds behave different from what I expected) because no valid JDK was found/supposed to be available/configured and the toolchains requirements in the I also found and fixed a bug in my implementation and improved the tests as well. Asking for in-depth examples was a good idea Additionally, I discovered that the If you have any further questions or need better examples (for an arbitrary value of "better") please let me know. |
Just got the pipeline notifications … gonna fix the formatting issues etc. Could have sworn I ran that formatting etc. after checking with the readme/contribution guidelines. Sorry about that :( |
As an aside and something that was not yet fully addressed I believe in either the PR or the issue: we can make the toolchains generation optional/opt-in and properly document that in the readme. This would ensure there are absolutely no breaking changes for existing users with working solutions and reduce the maintenance/support headache you rightfully pointed out – if they ever get around to upgrading (and reading about the changes in the update) they can still decide to switch. New users will hopefully see the notes and decide for themselves what they like best. Any thoughts? Personally I am fine with either. |
There are some CI failures. Running |
16eadc0
to
4043b21
Compare
Along with review fixes I did some additional changes pertaining to this:
|
@Okeanos mayn many thanks this looks really great! |
I've been thinking about this and haven't come to a decision yet ... I'm leaning towards doing it though. Since the intent is to avoid a potential breaking change, we would have to set it to |
Take your time – I am in no rush and just happy this is considered for integration. Waiting another few days and fixing any outstanding issues in the meanwhile is not a problem for me and I'll gladly try to incorporate any changes you would like to have made. |
Could you please sync with the main branch ? |
As far as I can currently tell the branch builds on top of the current main branch. The GitHub UI also says "This branch is 1 commit ahead of actions:main." the one commit being my commit introducing this feature. If you introduce any new commits to main before this is merged I'll incorporate those changes of course. |
@brcrista @dmitry-shibanov I'll be switching to |
4043b21
to
b7f3671
Compare
Ok, so I consider defaulting I think we can just remove the @dmitry-shibanov are you planning to merge #368 first? It seems like this PR will need some reaction work to add all Java versions to the Maven toolchain file. |
In that case I'll wait for #368 to be merged and make the necessary changes for that alongside removing the |
b7f3671
to
473afa6
Compare
@brcrista @dmitry-shibanov I updated the PR for setup-java to support Toolchains now that #368 (install multiple JDKs at once) has been merged. Based on the previous findings:
Compared to the previous iteration I did some additional changes for better compatibility with exiting setup options:
If there is anything else you would like me to change, let me know and I'll have a look. |
473afa6
to
b1de5e2
Compare
b1de5e2
to
18ea0e9
Compare
__tests__/toolchains.test.ts
Outdated
import io = require('@actions/io'); | ||
import fs = require('fs'); | ||
import path = require('path'); |
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.
Could you change this to the import * as ...
syntax? That avoids some subtle gotchas
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.
Doing that will throw "Cannot redefine property" errors because of the spyOSHomedir = jest.spyOn(os, 'homedir')
in the test setup. Interestingly it works for core
(where we do the same thing).
I am not well versed enough in either TypeScript or Jest to propose a better alternative. Any suggestions?
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.
I went ahead and fixed this for all except os
for now.
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.
A couple minor comments, but nothing blocking merge. @dmitry-shibanov could you or one of your teammates take a look also?
18ea0e9
to
6a9be81
Compare
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.
Go for it!
* Add (optional) Maven Toolchains Declaration after JDK is installed * Extract common/shared Maven constants Resolves actions#276
6a9be81
to
eb1418a
Compare
Thank you @Okeanos ! |
Very great, when will it be release? |
Description:
Related issue:
#276
Check list:
I also used my fork + branch on a private repository's pipeline to verify a valid toolchains declaration is created for the specified JDK and used by a Maven based build job.
Technically, using
${env.JAVA_HOME}
inside thetoolchains.xml
file is possible, however, this will get interesting with #44 very fast. Not to mention that e.g. version and vendor are not exposed as variables anyway.