Per issue #42, creating an issue to track the TODO that appears on line 14 below:

Is your feature request related to a problem? Please describe.
For people who are not already familiar with the tech stack, it may not be immediately obvious how to go about building the software or what environment variables are required to run the application.

Describe the solution you'd like
Add a short section to the README with documentation about the environment variables used, and how to build and run the application using the gradle wrapper scripts.

Describe alternatives you've considered

• Publish application as a .jar to the releases page, and add instructions on how to run the jar to the README.
• Publish a docker image to Docker Hub or GitHub Container registry, and add instructions on how to run the docker container to the README.

Describe the bug
Gradle is able to complete the assemble, build, bootJar, bootRun, and test, tasks. When executing via bootRun, the application runs normally. However, when executing the jar, the application crashes with a stack trace showing the following error: java.io.FileNotFoundException: class path resource [computer/gpu.json] cannot be resolved to absolute file path because it does not reside in the file system.

To Reproduce
Steps to reproduce the behavior:

1. Build the jar.

  gradle bootJar

2. Set appropriate environment variables.
3. Execute the jar

  java -jar build/libs/kyle-newer-0.0.2-SNAPSHOT.jar

4. Wait for Spring to initialize.
5. Observe crash and stack trace.

Expected behavior
The jar file does actually contain the "missing" file at the correct location, so it should work without crashing.

Screenshots

Stacktrace text:

Error starting ApplicationContext. To display the conditions report re-run your application with 'debug' enabled.
2022-04-25 04:29:31.113 ERROR 319 --- [           main] o.s.boot.SpringApplication               : Application run failed

java.lang.IllegalStateException: Failed to execute ApplicationRunner
        at org.springframework.boot.SpringApplication.callRunner(SpringApplication.java:771) ~[spring-boot-2.6.6.jar!/:2.6.6]
        at org.springframework.boot.SpringApplication.callRunners(SpringApplication.java:758) ~[spring-boot-2.6.6.jar!/:2.6.6]
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:310) ~[spring-boot-2.6.6.jar!/:2.6.6]
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:1312) ~[spring-boot-2.6.6.jar!/:2.6.6]
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:1301) ~[spring-boot-2.6.6.jar!/:2.6.6]
        at io.github.kjm015.kylenewer.KyleNewerApplicationKt.main(KyleNewerApplication.kt:85) ~[classes!/:na]
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:na]
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[na:na]
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:na]
        at java.base/java.lang.reflect.Method.invoke(Method.java:568) ~[na:na]
        at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:49) ~[kyle-newer-0.0.2-SNAPSHOT.jar:na]
        at org.springframework.boot.loader.Launcher.launch(Launcher.java:108) ~[kyle-newer-0.0.2-SNAPSHOT.jar:na]
        at org.springframework.boot.loader.Launcher.launch(Launcher.java:58) ~[kyle-newer-0.0.2-SNAPSHOT.jar:na]
        at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:88) ~[kyle-newer-0.0.2-SNAPSHOT.jar:na]
Caused by: java.io.FileNotFoundException: class path resource [computer/cases.json] cannot be resolved to absolute file path because it does not reside in the file system: jar:file:/mnt/c/Projects/New-Kyle/build/libs/kyle-newer-0.0.2-SNAPSHOT.jar!/BOOT-INF/classes!/computer/cases.json
        at org.springframework.util.ResourceUtils.getFile(ResourceUtils.java:217) ~[spring-core-5.3.18.jar!/:5.3.18]
        at org.springframework.util.ResourceUtils.getFile(ResourceUtils.java:180) ~[spring-core-5.3.18.jar!/:5.3.18]
        at io.github.kjm015.kylenewer.util.computer.compcase.CaseLoader.retrieveFromFile(CaseLoader.kt:23) ~[classes!/:na]
        at io.github.kjm015.kylenewer.util.computer.compcase.CaseLoader.run(CaseLoader.kt:15) ~[classes!/:na]
        at org.springframework.boot.SpringApplication.callRunner(SpringApplication.java:768) ~[spring-boot-2.6.6.jar!/:2.6.6]
        ... 13 common frames omitted

Desktop (please complete the following information):

• OS: Linux 5.10.102 / Debian 10 (buster)
• Java: OpenJDK 64-Bit 17.0.2+8-86 2022-01-18
• Package version: 0.0.2-SNAPSHOT
• Commit: f7fa67d

Additional context
The code responsible for the crash is in PowerSupplyLoader.kt#L22-L23.

ResourceUtils::getFile(String resourceLocation) always returns a java.io.File object. That works fine when the resourceLocation is pointing to a location on the file system, but it does not work when the resourceLocation is pointing to a path within a jar file, since items inside a jar archive do not exist as individual files on the file system and therefore cannot be java.io.File objects.

Potential solution
In the above code ObjectMapper::readValue(File src, Class<T> valueType) deserializes the json file. However, readValue can read from multiple input types, not just File:

• byte[]
• java.io.File
• java.io.InputStream
• java.io.Reader
• java.lang.String
• java.net.URL

To support jar files, the ResourceUtils::getURL(String resourceLocation) method can be
called in an identical fashion to return a java.net.URL object which can be consumed by
ObjectMapper::readValue(URL src, Class<T> valueType) in the exactly same way as a
ObjectMapper::readValue(File src, Class<T> valueType) without changing any other logic.

Describe the bug

• The bot does not make full use of the budget, even when it is capable of generating a more expensive build within the budget constraints. For example, if given a budget of 850, it will spit out a build costing 826.91, but given a budget of 827, it does not provide that build.
• Some budgets cause the bot to throw a NullPointerException, which is always interpreted as a budget that is too low, even when the budget is higher than many valid builds.

To Reproduce
Steps to reproduce the behavior:

1. Ask for a computer with budget of various values between 800-875.

   !kyle computer 850

2. Notice that the whole budget is not used.

   Total Cost | $826.91

3. Ask for a computer with budget of 900 or 1000.

   !kyle computer 900

4. Notice that the bot acts as if the budget is too low.

   Sorry, it seems you can't afford that right about now!

Expected behavior
The bot should always return the best computer available at a given budget, including budget of 900 and 1000.

Screenshots

Additional context
Terminal output:

2022-04-26 02:39:09.695 ERROR 536 --- [inWS-ReadThread] i.g.k.newkyle.commands.ComputerCommand   : Failed to create PC for user "chigeek" -> java.lang.NullPointerException

Is your feature request related to a problem? Please describe.
The README.md has some stale badge URLs from before the repository was renamed from Kyle-Newer to New-Kyle. The github stargazers badge still works because stars are automatically redirected when a github repository is renamed. However, the codefactor badge is a now broken image, and the travis-ci badge shows build|unknown.

Describe the solution you'd like

• Update the stale URLs to reflect the new repository name "New-Kyle".
• Reconnect Travis CI.

Describe alternatives you've considered
Revert back to the old repository name instead of fixing the links.

Additional context

this is a fake issue jk

Is your feature request related to a problem? Please describe.
This project is difficult to build and deploy reliably, especially for those not familiar with this tech stack. It requires specific versions of JDK and other dependencies, and environmental variables which are not documented in the README.md.

Describe the solution you'd like
Adding Dockerfile, docker-compose.yml, and example.env files to the root of the repository along with a short information section in the README.md would greatly ease the process of building and deploying, especially for newcomers.

Describe alternatives you've considered
Vendor-specific implementations for automated builds and one-click deployments:

• GitHub: GitHub Actions, GitHub Packages, GitHub Container Registry
• Heroku: Deploying with Git, Creating a 'Deploy to Heroku' Button
• Travis CI: Customizing the Build

Describe the bug
When travis runs the ./gradlew assemble command, the :compileKotlin task fails with error "peer not authenticated"

To Reproduce
Steps to reproduce the behavior:

1. Push a commit
2. Visit https://app.travis-ci.com/github/kjm015/New-Kyle
3. Scroll down to about line 197 and expand the install step with command ./gralde assemble
4. Scroll down to about lines 213-227

Expected behavior
The "peer not authenticated" error means that there was a problem with the TLS handshake. The certificate for jcenter.bintray.com is a valid for *.bintray.com, signed by DigiCeter, from Mon, 25 Oct 2021 00:00:00 GM. The URL https://jcenter.bintray.com/com/jagrosh/JLyrics/0.4/JLyrics-0.4.pom can be downloaded via curl 7.47.0 on Ubuntu 16.04 without issues, so it should be able to be downloaded by Travis CI as well.

Screenshots


Text:

$ javac -J-Xmx32m -version
javac 11.0.2
$ ./gradlew assemble
[...]
> Task :compileKotlin FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':compileKotlin'.
> Error while evaluating property 'filteredArgumentsMap' of task ':compileKotlin'
   > Could not resolve all files for configuration ':compileClasspath'.
      > Could not resolve com.jagrosh:JLyrics:0.4.
        Required by:
            project :
         > Could not resolve com.jagrosh:JLyrics:0.4.
            > Could not get resource 'https://jcenter.bintray.com/com/jagrosh/JLyrics/0.4/JLyrics-0.4.pom'.
               > Could not GET 'https://jcenter.bintray.com/com/jagrosh/JLyrics/0.4/JLyrics-0.4.pom'.
                  > peer not authenticated

Build system information

Build language: java
Build dist: xenial
Runtime kernel version: 4.15.0-1098-gcp
openjdk version "11.0.2" 2019-01-15
Gradle 7.4.2

Additional context
TLS errors can be caused by older versions of JDK which can have different implementations of TLS, with different TLS versions supported (TLS 1.2, TLS 1.3), different behavior for TLS client hello, and different trusted root certificate authorities. Some possible workarounds for similar problems found online included:

• Changing the repository URL from https to http to avoid TLS altogether.
• Upgrading to a newer version of JDK, eg from OpenJDK 7 to Oracle JDK 8, or upgrading from OpenJDK 11 to OpenJDK 13.
• Manually adding certificates to the trusted key store.

Potential avenues to explore

• The version of OpenJDK that Travis CI is using (11.0.2) is pretty old, and nearing end of support (Oracle Java Premier Support: September 2023, RedHat OpenJDK Support: October 2024, Oracle Java Extended Support: September 2026). The file build.gradle.kts defines the Java compatibility at JavaVersion.VERSION_12, so JDK 11 would not be appropriate. Building with OpenJDK 17.0.2 does work locally, and might solve the problem in Travis. Per the Travis CI docs on Using Java 10 and later, the .travis.yml can be modified to use a specific JDK version.
• Ubuntu 16.04 "xenial" is also pretty old and is no longer within standard support. Might as well change that at the same time. Newer releases are supported:

  Version	Code name	End of Standard Support
  Ubuntu 22.04	Jammy Jellyfish	April 2027
  Ubuntu 21.10	Impish Indri	July 14, 2022
  Ubuntu 20.04 LTS	Focal Fossa	April 2025
  Ubuntu 18.04 LTS	Bionic Beaver	April 2023
  Ubuntu 16.04 LTS	Xenial Xerus	April 2021

It's all the rage these days. Also, it's probably better we put in the tests sooner rather than later. One of you guys should start implementing test classes if you know how to.

We need to be able to avoid having dummy variables in the .properties file, and instead have references to environment variables that work.

Is your feature request related to a problem? Please describe.
CodeFactor is currently complaining about two minor issues in the cleanup branch that should be fixed prior to PR #37.

CodeFactor warnings included below for convenience:

Complex Method complexity = 17
Long or complex methods may lead to code that is difficult to understand and change. Such code may also attract abusive use of comments when a small method or variable are viable alternatives. The key to understand about small methods is good naming. If you have a good name for a method you don't need to look at the body.

Refactorings

• Extract Method
• Replace Temp With Query
• Replace Conditional with Polymorphism
• Replace Method with Method Object
• Decompose Conditional
• Preserve Whole Object
• Introduce Parameter Object

This comment contains 'TODO:' that has been defined as forbidden in detekt. lines of code = 1
Developers often add comments to code which is not complete or needs review. Most likely you want to fix or review the code, and then remove the comment, before you consider the code to be production ready.

Further Reading

• Detekt - ForbiddenComment

Have your own Detekt rules? No problem, simply add detekt.yml file to the root of this branch.
issue code: detekt.ForbiddenComment

Describe the solution you'd like

• Follow the Source Making recommendations for refactoring the complex method.
• Create an issue to track the planned enhancement and remove the TODO comment.

Describe alternatives you've considered

• Ignore the complex method for now, since it is a low severity warning.
• Create a detekt.yml file to allow TODOs in javadoc.

Additional context
Some IDEs can track TODOs that appear inside javadoc as tasks. However, these tasks might be better tracked in a project management tool, such as GitHub issues, where they can be prioritized appropriately.