Skip to content

Normalize extendedJavaHome environment variable #78

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.

Sign up for GitHub

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

Merged
konradpabjan merged 3 commits into from
Jun 22, 2020
Merged

Normalize extendedJavaHome environment variable #78

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
81bfa64
Normalize extendedJavaHome environment variable
aibaars Jun 17, 2020
655cb05
Add comment explaining why the environment variable should be normalized
aibaars Jun 17, 2020
8896560
Keep old environment variable for backwards compatibility
aibaars Jun 17, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions dist/index.js
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

6 changes: 6 additions & 0 deletions src/installer.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -87,6 +87,12 @@ export async function getJava(
}

let extendedJavaHome = 'JAVA_HOME_' + version + '_' + arch;
core.exportVariable(extendedJavaHome, toolPath); //TODO: remove for v2
// For portability reasons environment variables should only consist of
// uppercase letters, digits, and the underscore. Therefore we convert
// the extendedJavaHome variable to upper case and replace '.' symbols and
// any other non-alphanumeric characters with an underscore.
extendedJavaHome = extendedJavaHome.toUpperCase().replace(/[^0-9A-Z_]/g, '_');
Copy link
Contributor

@ericsciple ericsciple Jun 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a breaking change. Should the old variable be set also, so existing customers dont get broken?

Copy link
Contributor

@konradpabjan konradpabjan Jun 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. It could break certain users if they're actually able to use the current variable.

When we eventually release a v2 version of setup-java, then we can remove the old one (we don't promise compat between the new versions).

Copy link
Contributor Author

@aibaars aibaars Jun 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, I just pushed a new commit that keeps the old variable.

core.exportVariable('JAVA_HOME', toolPath);
core.exportVariable(extendedJavaHome, toolPath);
core.addPath(path.join(toolPath, 'bin'));
Expand Down