search

microsoft / azure-pipelines-agent

Azure Pipelines Agent 🚀
MIT License
1.73k stars 869 forks source link

Self hosted agents does not detect java capability for OpenJDK #3624

Open groogiam opened 3 years ago

groogiam commented 3 years ago

Agent Version and Platform

2.193.1

OS of the machine running the agent? OSX/Windows/Linux/... Windows

Azure DevOps Type and Version

dev.azure.com

If dev.azure.com, what is your organization name? https://dev.azure.com/flairsoft

What's not working?

The build agent does not seem to detect "java" capability for OpenJDK installations. This is described in #3402 and the last comment references this as fixed. The issue does not appear to be fixed as of 2.193.1 java is still not detected when OpenJDK is installed.

EzzhevNikita commented 3 years ago

Hey, @groogiam, the agent is using register keys for detecting java capabilities. Are you sure that AdoptJDK added an entry into the register? Currently, the agent checks the set of register keys described in this file.

groogiam commented 3 years ago

@EzzhevNikita I usually install OpenJDK with choco https://community.chocolatey.org/packages/openjdk which I'm guessing does not create these keys. I there a reason that the logic has opted to check for registry keys rather than java being on the path or a JAVA_HOME environment variables? Seems like this might be a more robust way of checking for a java environment. Thanks for your help and quick response.

EzzhevNikita commented 3 years ago

@groogiam The main reason why we are using reg keys is that they are machine-specific, while env variables could change from user to user. And generally, registry keys are a more common and robust way to look for the installed programs on the machine.

groogiam commented 3 years ago

@EzzhevNikita This example seems to point to the contrary. I'm still failing to see why env variables are not the best option here. Yes they can be different from user to user but they would either be set system wide or on the account the agent service is running as. In either case the mechanism seems like it would work. I'm curious how this check is done on a linux agent. Seems like there might be an opportunity here to make this check more consistent across both linux and windows.

github-actions[bot] commented 2 years ago

This issue has had no activity in 180 days. Please comment if it is not actually stale

groogiam commented 2 years ago

@EzzhevNikita Any update on how this check is done on linux?

Dylan-Prins commented 2 years ago

How can nobody comment on this?

sumit84mca commented 2 years ago

I used task JavaToolInstaller (https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/tool/java-tool-installer?view=azure-devops) Now its working. image

github-actions[bot] commented 1 year ago

This issue has had no activity in 180 days. Please comment if it is not actually stale

groogiam commented 1 year ago

Can someone please provide some details on how this check is performed on Linux and why it can't be performed in a similar way on Windows?

github-actions[bot] commented 1 year ago

This issue has had no activity in 180 days. Please comment if it is not actually stale

groogiam commented 1 year ago

Can someone please provide some details on how this check is performed on Linux and why it can't be performed in a similar way on Windows?

github-actions[bot] commented 12 months ago

This issue has had no activity in 180 days. Please comment if it is not actually stale

groogiam commented 12 months ago

Can someone please provide some details on how this check is performed on Linux and why it can't be performed in a similar way on Windows?

ofgirichardsonb commented 8 months ago

Agreed. Chocolatey is a common method of installing required system binaries. If the check on Linux doesn't require registry keys, then why can the Windows one not do the same check? This seems like an arbitrary restriction that is not adequately addressed by the JDK tool installer.

ofgirichardsonb commented 8 months ago

I see that this issue is now over 2 years old, and Microsoft is clearly just going to let it mothball. Regardless of what happens, I will have to do additional maintenance work and/or build a Linux build server to get this going, and I won't pursue it any further than this last comment. Frankly, it's not a good look to leave issues to die, especially when there are only 113 issues in the list. Perhaps the reason is that it's not a particularly defensible position to close as "WONTFIX"?

sicil1ano commented 4 months ago

I am having a similar problem detecting the Temurin JDK installed in a self-hosted agent running Linux. I am using the exact same image used by Microsoft for their hosted agents to run an Ubuntu 22.04 agent (https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml and https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2204-Readme.md) and JAVA_HOME environment variables are not appearing.

I think the reason why those environment variables are not appearing is that Temurin JDK is not supported. Please see this for details: https://github.com/actions/runner-images/blob/main/images/ubuntu/scripts/build/install-java-tools.sh

rdebath commented 3 months ago

To answer the badbot message the Unix versions of the agent don't bother to detect anything. Instead a bodge script copies a few of the env variables of user who installs the script into a file $Agent_HomeDirectory/.env. The contents of that file are added to the real environment of the Agent on startup just like $Agent_HomeDirectory/.capabilities.

I guess the best, sort of, solution is to bodge it the same way.