#JShell project for Tj-Bot!
1 messages ยท Page 7 of 1
but grpahana for us would be a.. bonus feature
we survived without it
it that subsystem fails for whatever reasons, we will be fine
if it's designed in a modular way like that
You survived without it, I can't 
I hate that I couldn't find where jshell was invoked manually in the server
I fr checked bots, spam, chitchat, questions
Maybe I'm blind, I couldn't find it
yeah, you don't have diagnostic tooling
you don't have that one faulty session to investigate
you are not even aware where it happened
and why
what was the input.. etc
We don't even log it in the logging channels that somebody invoked a command:(
this can all be improved
for example sessions that failed, errored out, could be perserved for 14 days
wdym, how could you not find it ?
Yes kinda
so if nothing else, you can manually play with them
Skill issue prob
Let me find what you want
you kinda want everything, because currently it's hard to triage and reproduce bugs
and investigate
because it's just random sessions being spawned and killed
so if there is issue, you only have logs
logs are improved now tho, right?
#infra-status message how about the most recent
that's easy, pick one that is not active 
wdym
Or groovy
Or ruby
I wish ๐ฆ
Tbh
I'm gonna suggest something crazy
But it's rewriting jshell
So we can support everything
i mean, project like that would...
Now that we have it working on the vps
we could make it commercial :p
Less than a week, I have a solution
It's not
it always looks easy, until you realize how many complexities there are
but it would be a top product on the market
it runs any code
There are two entry points for calling jshell in tj bot :
https://github.com/Together-Java/TJ-Bot/blob/develop/application/src/main/java/org/togetherjava/tjbot/features/code/EvalCodeCommand.java
https://github.com/Together-Java/TJ-Bot/blob/develop/application/src/main/java/org/togetherjava/tjbot/features/jshell/JShellCommand.java
If you want to collect stats, you could add that in class
https://github.com/Together-Java/TJ-Bot/blob/develop/application/src/main/java/org/togetherjava/tjbot/features/jshell/JShellEval.java
Since all calls pass by here.
@sterile crest
I have the solution in my head
So
I wish I had my own discord bot in this server ๐ฆ
you can send output to email or your messaging server of choice
If you want to add graphana
just add code in JShellEval in TJ-Bot
and you are done
easy @sterile crest
or in your terminal, like universal repl for every language
Okay you're misunderstanding how it works
But yes it's easy
No man
/jshell lang=ruby code=whatever
your head must be so big right now 
Then for the docker part, just use the official docker image for the language
And just <command> <code>
And spit out the results
yeah, whole AWS paltform is basically just few 'justs'
just spawn a server, just spawn an image and run it for 30 seconds
i mean, every software is 'just'
My brain is just bigger than yours 
most shit we work on are basic CRUD apps, like websites
you get some text, you pull something from the database, you send it back
easy 
Yeah
Easyyy
Peasy
Lemon
Squeeezyyy
I'm weeezy
Like breezyy
Now I'm rapping
Problem is that jshell is a REPL, I coded it in a way to expect a REPL
So we can only use languages that have a REPL

unless we do some magic
Yeah magic called abstraction
but yea it could work
you would only need to add a new wrapper
for each language
Exactly
You got itt
You understand

I want my own bot added to TJ ๐ฆ we can call it TJ community commands Bot
and the thing is that the wrapper doesn't use json or any complex format, so you don't even need any lib in the wrapper
Where people submit their own fun commands
I'm gonna suggest it
Where's the channel
#server-suggestions
yeah, in theory it's all simple and cool
because we built our own in-house aws lambda
and we can run anything on it
You're acting like I can't POC the idea in under day

that's why we have api, thinking about the future man (that you had doubts about, and thought was a dogshit idea) 
#server-suggestions message
It is dog shit
Unless we're taking outside of TJ and making money 
@timber mirage btw the way graphana works is...
We pull a docker image and that will start a web server
Then from any of our services we just push the metrics to a data source (e.g. promethius or a sql database)
And on the graphana website that it spun up, we can see the raw metrics that we collected and start making graphs for it
I.e. a new web page that contains stuff
E.g. "jshell" then all the stuff
And "TJ slash commands", "TJ errors" etc etc
Or however you want
We have flexibility on how we visualise the data
If I remember correctly, the graphs are just json files e.g.
{
tile: {
name,
x
y
data
aggregation
}
}
Some shit like that
uh no
Whatsp
@bright lark any advancement ?
hi
not yet got some pressure recently at work
i'll try to check asaic
alright
yesterday when i replied i was in bed
unable to sleep and got multiple notifs from u
so i wanted to join by phone
(i wasn't in front of laptop)
Take your time
right, so im gonna do the fixes and what then ?
if we agree on a final approach, i'd probably go to the next usecase to write test for it
(btw im gonna explain what i did in readme)
yes please
hi again and sorry i couldn't find enough time for pr review today, maybe tomorro stay tuned
hello @timber mirage ! please answer me here https://github.com/Together-Java/JShellPlaygroundBackend/pull/50#issuecomment-2347256728
i mean on discord
to move faster
thanks in advance
26 lines to test a simple 2+2 and you call your test simple ? it's also extremely redondant
for the second point, I am asking to test for state
I removed the constants
So u want to put the webtestclient chaining inside utility method?
So it becomes testEval(args)
Right?
I gave an example
where ?
a list ?
boolean isValidResult = result.snippetsResults()
.stream()
.filter(res -> res.result() != null)
.anyMatch(res -> res.result().equals(TEST_CODE_EXPECTED_OUTPUT));
This checks if result has 4
why don't you just check there everything is correct ?
why can't you do what i said ?
i don't understand
I did
?
Ive checked tht everything is correct in the isValidResult variable
but that's not what i asked
I asked to simplify the tests
and add a test to test state
Why no?
because we have no idea if your approach works with state
yes
My approach in the current test works just fine
No need to go faraway from this basic scenario
When i add the second test, i may do that
We agreed on setting one test in my pr, remember?
we need this second test
Hmm
I didn't think about it
But i still dnt see the reason to block pr for tht, the wrapper container is shutdown when the test is finished
I mean we can merge the pr
Without adding another test
Anyway if u insist then i dnt have choice
Gotta go sleep now sorry, ill get back tomorro
we can't because we don't know if it will work if you don't do this test
Anyway if u insist then i dnt have choice
I mean, try to understand why it is needed
i know it's needed !
but i just want to set exactly 1 test
in this pr and next we do others
as agreed previously
You misunderstand, it is needed for this pr, it's not a random test
this pr is about testing one scenario in 1 endpoint
the test u want me to add is a second scenario
and ok np

Firas is right though
Unless the test you're requesting is directly related to a change he has made
It is
No, the pr is about creating the infra to make tests
And the reason we need tests is to verify that the infra works
huh
i didn't say no to that
i assume all integration tests are obviously relevant to infra
but nm
Hi again! @timber mirage the next test is about using same session id (e.g: "test") used for "2+2" but with java expression right ?
store the 2+2 in a variable, and reuse this variable in the second call
testEval(testEvalId, "2+2", "4");
testEval(testEvalId, "2-1", "1");
ah !
that means i must get same result again ?
testEval(testEvalId, "int a = 2+2", "4");
testEval(testEvalId, "a * 2", "8");
@bright lark
if you are correctly using the same session, the variable "a" should exist
also can you do it the way I gave you in the first point ?
i did like this
but what if you want to test anything else than the result ?
like wat ?
Anything that is in JShellResult
wdym
the result is as expected
the response is success
What do you not understand ?
u want me to check something else
but you didn't check any of the other fields, how can you know that ?
the http response header is enough to tell if it successful or not
no it's not
please check everything
it doesn't even cost you more lines of code that what you currently have
status ?
for example
no
add everything
this should only take one minute
because you can't just check one of the values and assume that everything is correct ?
i mean result and status are obviously enough
but ok
it cost nothing to check everything
and no, it's not enough
testEval(testEvalId, "int a = 2+2", "4", SnippetStatus.VALID, SnippetType.ADDITION);
testEval(testEvalId, "a * 2", "8", SnippetStatus.VALID, SnippetType.ADDITION);
no
first of you didn't test everything
and I gave you the solution
just do what I told you to do
Your test is too complicated to test something too simple, you need to simplify it, create methods or classes for this so your test can be as simple as for example assertEquals(sendEval("2+2"), new JShellResult(...))
ok
assertThat(testEval(testEvalId, "int a = 2+2;")).isEqualTo(new JShellSnippetResult(SnippetStatus.VALID, SnippetType.ADDITION,1,"int a = 2+2;", "4"));
assertThat(testEval(testEvalId, "a * 2")).isEqualTo(new JShellSnippetResult(SnippetStatus.VALID, SnippetType.ADDITION,2, "a * 2", "8"));
yes
wait
alright we're don..
why not JShellResult
i think we'll not end
Why don't you just do what I asked days ago ?
Why do you try to hard to find a way to not do that ?
dnt be mad
alright it's done
im gonna commit
now i'm writing some docs in readme
@timber mirage all is done !
@timber mirage wanna setup graphana and promethius with me?
promethius is what we'll use as a data store and graphana is how we'll create pretty charts
but i'm worried we'll have to fk around with networking so maybe we can get something working locally first and then... think about how to deploy it with marko, without having the same issues we did with jshell
since we need to expose 2 things:
- promethius to graphana and tj
- graphana to the web
why not
I need to remember how to do this
I think TJ needs to export a website with metrics?
why u dnt use spring boot admin
can you explain spring boot admin?
where in TJ are we using spring?
we can perhaps use the existing spring stuff in jshell to expose the metrics
prometheus:
image: prom/prometheus:latest
container_name: prometheus
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
command:
- '--config.file=/etc/prometheus/prometheus.yml'
ports:
- 9090:9090
grafana:
image: grafana/grafana:latest
container_name: grafana
ports:
- 3000:3000
environment:
- GF_SECURITY_ADMIN_PASSWORD=admin
(keeping this here so we don't lose it) - it's the docker-compose config
prometheus.yml ```
global:
scrape_interval: 15s
scrape_configs:
-
job_name: 'prometheus'
static_configs:- targets: ['localhost:9090']
-
job_name: 'java-app' # You will update this to your app's details
static_configs:- targets: ['<your-java-app-ip>:8080']
@sterile crest why do you try so much to make the aws solution comes into tj bot ?
what do you expect to do with it ?
where is AWS
you mean the PR?
Marko asked to see it, I only spent maybe 2 hours creating the PR and left it, idc if its merged or not
yes
you probably didn't take 2h to do it
it was 2 hours
less than 1 day, when I originally did the POC, it took 30 mins
remember, there's no docker, or any complicated logic
it's a simple eval API, that's it, no sessions etc
such api, I had one in late 2023
yes it took more time, but 6 months, it was 6 months waiting mostly
anyway
everything is a wrapper over this:
that's jshell
and then in AWS I am just OBJECT_MAPPER.writeValueAsString(JShellOutput); and AWS side is done
the rest was just the slash command
the PR looks big, but's mainly c&p from other projects I've done in the past
but again, idc about that solution now
though, with AWS we could skip promethius ๐ฆ
but we have to set that up now and all the complexity around getting metrics exposed
OTel's not that hard to implement in and of itself, but properly defining what to track is another matter.
And having enough people with the required rights.
anyway yes, tell me if you need help
but, why not setting up that on tj bot directrly ?
don't think you can?
wdym
Hello, wdym ?
nono
try to install the project then
okay just a moment
installed
no its not
then read the readme and try to run it
tell me if you have any question
this is the repo
u can check it out
okay will reach you out
thanks man)
it's stuck on second command
how can i help you out?
wdym
first of all, i got a problem with running JShellWrapper:run
and i tried to ./gradlew bootRun
and it doesn't work for me
stuck on 88% messaging
2024-09-14T18:45:51.920+05:00 INFO 12684 --- [pool-2-thread-1] o.t.j.service.JShellSessionService : Scheduler heartbeat, sessions ready to die: []
wdym, does it print this log endlessly ?
yep
while at the bottom
Executing: 88%
<===========--> 88% EXECUTING [7m 20s]
and also about JShellWrapper:run
it is giving an exception requiring me to accept Terms&Conditions at gradle website
Ah the problem is with env variables
follow The readme file
U need to 2 env variables with specific values to make it run
U need to use comma
Rather than semicol
Between the variables
Thats how it works in intellij
okay just a moment
And dnt use spaces
what about this
okay
if you executed JShellAPI, that's normal i guess
ahhh then okay
how much it actually takes to make a run
Seconds ig
JShellWrapper:run i mean
it is going minutes for me
U need to understand somthing here
U dnt have to run jshellwrapper by yourself
It is implicitly done by jshellapi
All u have to do is build the jshellwrapper img
And use post:eval endpoint
If u do, jshellapi communicates to docker and runs the img
Making it living for a period of time (session)
okay thanks
@rotund kernel so ?
ran it
but thinking about port 8080
Web server failed to start. Port 8080 was already in use.
Action:
Identify and stop the process that's listening on port 8080 or configure this application to listen on another port.
i couldn't be able to kill it
it is creating one auto
are you already using port 8080?
yep
will change the config file
after will set it to default
okay
@bright lark I reviewed your pr
Basically, you are transforming the readme into a report showing what you did... that's not what a readme is for
And some other changes
Ah and specifically one of them, is it possible to make so tests use a custom config file ?
any advancement ?
I agree with Ala's comments on the README
hello
im checking ur comments
it looks like u didn't like
i tried to do some stuff as i thought about newcomers (new learners)
Ah and specifically one of them, is it possible to make so tests use a custom config file ?
sure
you'd like to set a config record and properties like the one under src/main ?
Basically setup a custom application.yaml but for tests
And the idea is that different tests can use a different one
I explained this in the readme, this is at best the wrong place.
And there are many things you put that won't help anyone anyway
What's the point of copy pasting the build.gradle, can't people just check it out ?
What's the point of copy pasting gradle rules, like file structure ?
Why do you need to explain each line of code you did in the readme ?
What's the point of saying that you, and us did this work in a random place in the readme ?
You are supposed to make doc for this, javadoc or equivalent for this
You are just making a report for a school project.
Also remember that readme purpose is to explain people how to use the project, not how to explain how it works.
Seriously, if I really did what you did but for the whole project instead of your test, the readme would be 10k lines long, it would be unreadable.
I see. Well it's cuz u said u dnt know about gradle and my changes
So i thought i have to write some friendly hints to help unfamiliar contributors to understand
Somebody may not know about injecting the image name from root build.gradle file to subprojects
Also i tried to let know that the test class is about integration test and that it depends on additional configs in build.gradle file
Now i dnt have much time to discuss sorry. Will come back soon
But thanks for ur feedback
You can still have the documentation that you want just not on the parent README or in file comments that don't make sense
Instead, what we can do is create a docs folder that contains all our documentation as .md files
Yeah even a docosaurous module
but even then, many of the things you wrote shouldn't be there
like there is no point to write gradle or maven rules
like when you said where the tests should be located
Maybe it's better suited for some contributing guidelines but whatever the case, there should located somewhere more specific for docs
and you need to make a difference between choices that you did and that you want to remember by writing them out
and actual explanation about how the project works
first is only useful if you need to edit that specific line of code
second is useful for everyone
there should be just an abstract overview how testing works, with simple example
the example is quite literaly the test itself
basically a broad guide on how to write tests on our project
it's still out of the scope of the main readme
obviously ^^
Hello
Use Objects.requireNonNull instead of abusing Optional.
i wonder why u say that @timber mirage
Ignore this one since you won't need it if you fix the previous comment
i assume your review was too strict
but i like it
invalid link, is this a bot to teach java?
Ah, it was the test server, now that it was deployed, it's useless to give it anyway.
And no, it's just jshell
Snippets
Snippet 23, VALID
2+2```
jshell> `4`
## System out
[Nothing]
this
๐คฏ

Snippets
Snippet 23, VALID
Random random = new Random();```
jshell> `java.util.Random@67117f44`
## System out
[Nothing]
Snippets
Snippet 24, VALID
random.nextInt(20) + 1```
jshell> `19`
## System out
[Nothing]
๐คฏ
you know you can use nextInt(1, 21)
i donut
try it ๐
Snippets
Snippet 25, REJECTED
nextInt(1, 21)```
## [WARNING] The code couldn't end properly...
Problematic source code:
```java
nextInt(1, 21)```
Cause:
The code doesn't compile:
cannot find symbol
symbol: method nextInt(int,int)
location: class
## System out
[Nothing]
random.nextInt(1, 21) I mean @fossil badge
Snippets
Snippet 26, VALID
random.nextInt(1, 21)```
jshell> `2`
## System out
[Nothing]
you can try to break it if you want #bots
Actually not im in a terrible pressure at work these days
But gonna check soon
alright
Tbh your review on my pr was legendary
It helped me a lot at work
So i reviewed some prs same way and it gives precious results
@timber mirage i think about removing some content in the readme as u suggested
and put it in the PR description instead (not everything and briefly)
is that ok ?
I mean, you probably want to delete everything you added
since none of it is useful for an user
huh
i thought automated tests aren't for user
yes ?
the documentation is to help other developers to understand the approach
it's not documentation either
you would need to add a wiki
which
isn't priority for now
in the pr itself ? you can
but remember, don't put things we already know or we can easily find, it's pointless to say where each file is, it's pointless to show code
and it's still not documentation
you don't explain to the programer how they should do it
you explain which challenegs you faced and the choices you made
this would have a place in the pr so we know how this was done
@bright lark actually, probably better to put such info in the issue, not the pr
so the issue has all info regarding the choices you made to make it work
@bright lark any advancement?
hello
what ?
ive finished
im waiting from someone to wrap up
Ah did you check the reviews I made?
Ah, I'll check that
ive just made a new update
@bright lark I made a review
there are some points you'right about
however ive answer u about others
Alright, replyied
i see to put 2 configs : common and specific ones
for dev and prod: merge common + devconfig
for test: merge commong + testconfig
fix jshell name yes, but not the variable you just added
why we dnt fix both ?
it doesn't make sense to keep one unfixed
You have to fix the one you added
And for the other one
it's not in the scope of this pr
and will cause many problems
because all the config files will need to be updated
In case you didn't understood
You added something
it's wrong
I am merely asking you to fix it
wdym
you added a variable
the variable doesn't follow conventions
i am simply asking you to fix it
but i think that properties aren't meant to follow camelCase!
when i see predefined properties in docs, all are lowercase
they are made to match the config class, if they match the variables in it, there is no doubt about how it will work
they can follow the variables in config class even in lowercase
like i did

still
and even if
you have to follow the conventions of a project
that's the most important thing
if a project started with a particular convention
then you must follow it
right
as for readme
i m going to just write the command to run tests
is that ok ?
or remove the section
Just remove the section I guess, we could add this later
yes remove it
another point please, ${jshellWrapperImageName} i m gonna change it
to uppercase with underscore
cuz it's like env variable
so i becomes ${JSHELL_WRAPPER_IMAGE_NAME}
jshellWrapperImageName: ${JSHELL_WRAPPER_IMAGE_NAME}
LGTM
yes do that please
what do u think about this ?
@timber mirage
only use hardcoded config, it's better i think
ye but i think about extracting some configs from Config
and put them in use in dev and runtime
and create a separate config for test that extends Config
in other words i'd have:
class Config extends CommonConfig {}
class TestConfig extends CommonConfig {}
no
to avoid redundancy
there is no redonduncy at the fist place
you are the one adding it
just create a custom config object for the test
why would i define the evaltimout twice?
as for the session it could customized
because it may be different ?
but that will not make test consistent
?
i think that integration test must follow the real scenario
if i set timeout in test lower or greater than the one used at runtime
they can't
we have a 30min timer
we can't make so the test takes hours
ye i agree to make that shorter
so i think that some configs need to be customized between test and runtime
some yes
but not some others
alright, so it would be a good idea imo to keep common ones centralized in one place
no
and create extensions
because we can't know which one will be common
we can decide
for example the session timeout
(it could be only this one)
๐
also your approach is just worse
you are saying that you reduce duplication
but you are not doing that
you are doing the opposite
especially when the original solution is one line long
i dnt see what u mean can u elaborate?
on what ?
the current solution is one line long
you are asking, to replace the record with three classes
no
so around 150 lines of code
you asked to create a copy from Config
new Config(foo, bar)
that's one line
no
well
kinda
it depends
either there is a test config
or we just new Config
this looks like a violation to properties
well
as i said earlier "as u wish"
both have advantages
the problem of having a second config
is that we can't customize it
and so our tests will be more limited
so it's not a choice
it's weither or not we know what the tests will contain
we can
how ?
it's valid to add a properties file under src/test/resources
no
that's not what I mean
what I mean is that we can't select different config for different tests
if we use a config file
we can
with profiles
@ActiveProfiles
but then it just makes things even more complex
well
I guess we could got for a single config file in resources
then we will change it later if needed
yes that's the point
and you shouldn't use inheritance for this
it's just a bad idea
Ok
@bright lark hello, any advancement ?
@sterile crest @compact holly hello, I just made a pr to update jshell to java 23 : https://github.com/Together-Java/JShellPlaygroundBackend/pull/54
I have a question, is it possible to make so it is automatic for the next versions ?
You can write pure java code inside your build.gradle
So write a method e.g. int getVersion() and use it
you don't want anything serious automated
I just want that it automatically create a pr
But that's too much effort to teach because it's also doing the work
You can create a GHA
Yes that's what I am asking, but how ?
I have no idea how GHA works
Can't you teach me ?
Hmmmmmmmmmmmmmm
@compact holly should I teach him or let him figure it out?
Actually
Teaching is a big job
Or at least, can you tell me where I can find the code that create those auto pr for dependencies ?
Look inside the .github folder
dunno, it's your time
Dunno has the word no, sorry ala 
but actions have docs, there are plethora of already made actions you can just use with a single line
Yes, "Dunno" does have the word "No" in it. "Dunno" is a colloquial contraction of "don't know," and it contains the word "no" within it. The word "no" is a negative particle used to express denial or refusal, while "don't know" is a phrase indicating a lack of knowledge or information about something. In this case, the contraction "dunno" combines these two elements into one word. It is important to recognize that language can be fluid and flexible, allowing for the creation of new words and expressions through processes like contraction. As such, while "dunno" may not be considered a standard term in formal writing or speech, it is commonly used in informal communication to convey uncertainty or lack of understanding. Overall, the presence of the word "no" within "dunno" adds to its meaning and serves as a reminder that language can evolve in unexpected ways.
it's probably a common thing with a ton of google results
Tf lol
Problem is that you did it in a certain way, and I have no idea how I should do it so it would match the conventions that you used
He didn't do anything in a certain way
There is nothing about auto updating the depdencies
it's all pretty standard stuff, that every project uses
There is in a .yaml file
Well, I think ?
basically 'getting stsrted guide'
The .yaml / .yml is how you create them
docker-publish.yaml
docker-verify.yaml
pre-commit.yaml
releases.yaml
Yess
there are those 4 files
Those are GHAs
There is also dependabot.yml that I have no idea what this is
Dependabot is a GitHub bot that automatically creates pull requests to update dependencies in a repository to their latest versions. It helps keep projects secure and up-to-date by regularly scanning for outdated dependencies and suggesting updates.
Look use the pre-commit as your base
you can see it in action in tj-bot
Ah so it's the one I need
But huh
version: 2
updates:
- package-ecosystem: "gradle"
directory: "/"
schedule:
interval: "weekly"
nearly empty
To create a GitHub Action (GHA) that can raise a Pull Request (PR) to change a line in your build.gradle file with an output from a bash script, follow these steps:
-
Create a new GitHub repository for your project if you haven't already done so.
-
In the root of your repository, create a new directory called
.github/workflows. -
Inside this directory, create a new YAML file (e.g.,
update-build-gradle.yml) and add the following code:
name: Update build.gradle
on:
push:
branches:
- main
jobs:
update_build_gradle:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Run bash script
run: |
OUTPUT=$(bash script.sh)
sed -i "s/old_line/$OUTPUT/" build.gradle
- name: Commit changes
run: |
git config --global user.email "[email protected]"
git config --global user.name "Your Name"
git add build.gradle
git commit -m "Update build.gradle"
git push
-
Create a bash script (e.g.,
script.sh) in the root of your repository to generate the output for the new line inbuild.gradle. -
Commit and push these changes to your repository.
-
Once the workflow is triggered by pushing to the
mainbranch, it will run the bash script, update thebuild.gradlefile, commit the changes, and push them back to the repository as a PR.
This GHA will automate the process of updating your build.gradle file with an output from a bash script and raise a PR for further review and approval.
yeah, like i said, it's default/standard stuff
To update the Java version in your project using Dependabot, follow these steps:
- Check the current Java version in your project by running
java -versionin your terminal. - Make sure Dependabot is enabled in your repository. If it's not, you can enable it by adding a configuration file (dependabot.yml) to the root of your repository.
- Dependabot will regularly scan your project for outdated dependencies, including the Java version. When it identifies an outdated Java version, it will create a pull request to update it.
- Review the pull request created by Dependabot to update the Java version. Ensure that all necessary changes are included and that there are no compatibility issues with other dependencies.
- Merge the pull request to apply the updated Java version to your project.
It's important to note that updating the Java version may require additional changes to your codebase, as newer versions of Java may introduce new features or deprecate existing ones. Make sure to test your application thoroughly after updating the Java version to ensure that it functions as expected.
If you encounter any issues during the update process, you can seek help from our community on the Discord server or refer to Dependabot's documentation for further assistance.
On top of that, it needs to check if the image is available, so can I do a http request in this ?
Yeah curl
Make a .sh that spits out the latest version and sed it into the build gradle
thank you
It kinda sucks but it'll work
heh
a simple curl should work
I just need to check the error code
or something like this
I think
Yup
You can curl inside the yaml, yes
one last question
is there a way I can test the action in local ? or do I have to create a test project ?
It's not
It's just raising a PR
That's it
If it breaks, we'll see a trash commit
Easier to create a test project ig
- name: Run stuff
run: |
curl <>
sed <>
Ah and also, if I need an account to send a http request to docker, how do I handle this .
you don't
it's not
wdym
use the docker API
it requires an account
curl -s "https://hub.docker.com/v2/repositories/library/eclipse-temurin/tags/?page_size=100" | jq '.results[].name'
anyways have fun

Oh u mean other fixes
how I forgot
Sorry will check tomorro
is it possible in the yaml to read the build.gradle ? since I would need to read the current java version...
- name: Checkout code
uses: actions/checkout@v4
when you do this, it'll checkout the code and you can run any linux commands you want
if you did a ls you'll see everything
so you can just read the line from gradle however you want
or better, use the gradle properties file
Problem is, how do I parse the gradle file ?
will there be multiple from.image?
match on a longer regex, from.image = 'eclipse-temurin: or match on the entire jib block and work your way down that way
this is where the properties file would have been better because it's easy to parse and use
Hmm I see
something like this:
sed -i "s/eclipse-temurin:$current_version/eclipse-temurin:$((current_version + 1))/" $GRADLE_FILE
do you want me to this for you
If you want, I'll check that regardless tomorrow
okay ill do it once you give up
Note that I will have limited internet starting Saturday, so I won't be able to push any contribution this week, only do reviews
So if I can't do it tomorrow, I will only be able to do it next weekend
Actually, can you do it please? Since I will be able to focus on other things for jshell
5min left ๐
I can't raise a PR
fml
I need to fork the project
I haven't tested the commit and create pull request
the rest works
well ig i can test it
gg tho @timber mirage
took less than 15 mins

works though
wym gg i can fix this in 2 seconds
whoops messed up the PR
@timber mirage is this OK?
Wrong file, see my pr, it's in the wrapper
now ay
lma
why is wrapper using eclipse-temurin:22-alpine and API is using eclipse-temurin:21
?
Because the api doesn't need alpine
can we not use alpine for the wrapper?
then i can just change the path to the wrapper without needing to change the logic to handle "alpine"
Alpine is lightweight
i know
It is needed so the wrapper weights less, it's critical
Anyway, I'll go to sleep
I'll merge your pr tomorrow if I don't see any problem
you can't find problems when you couldnt' find the solution ๐
๐ ๐
but the PR is all yours now
I don't wanna continue with it - it exceeded my 15 mins
30 mins is too much work ๐ฆ
okay whatever, i pushed the fix to use alpine and jshellwrapper
@compact holly check out my hacky bash!!
did u guys end up switching to wazei's aws?
whatsup
@timber mirage im resuming the pr review fixes
and i find that it would be better to make checkJShellWrapperImageName() public
so i can reuse it in TestsConfig class
System out
Version: 22.0.2+9
Vendor: Eclipse Adoptium
OS: Linux
Arch: amd64
Could not find session for member Nopox
@sterile crest I reviewed your pr
@bright lark you didn't address all the comments
once you addressed them, I'll validate it
feel free to make the changes, i won't be working on it - but the solution is there for when you need it
alright
are u kidding ?
i dnt see anything left
huh
u want to do that selection in the constructor DockerService or Config ?.
Dockerservice
And there is another comment iirc
what is it please
(cuz im lost in those +50 reviews)
I said in a comment
That's because of spotlessApply
Ig
It added an empty line at the end
ah
i think tht we should set git hooks
it seems tht code wasn't formatted
done
@timber mirage
I'm new to open source contributions and have been exploring the code base. From what I've gathered so far, it seems that a new container is created for each session. While Iโm still familiarizing myself with the entire context, I was wondering if it might be more efficient to implement a flexible pool of containers. In this approach, code snippets could be executed in an available container, which would then be refreshed (perhaps by restarting the JVM) and returned to the pool for reuse.
I understand that there may be details Iโve missed, and I apologize if Iโm overlooking anything important. I would greatly appreciate your insights on this idea.
There is a concept of sessions, where if you execute several sessions in a row, you can reuse the results of the previous sessions
So it's not possible.
What if you persist the state of those sessions after execution, to resume them when they are reused or delete them after expiration.
The state is in jshell itself, I have no control on it
Alright, but is it okay, if there was a way to persist session, that is if jshell offers a way to load up and save session in some format, or is it a dead end.
it's a dead end
unless you want to research for a way
Technically
We could spin up a single container and run multiple instances of jshell
However, you get gg'd if person crashes the container then gg to everyones sessions
I would definitely like to explore this idea further. It seems, though, that you might have some reservations about the approach. If thatโs the case, Iโd love to hear your thoughts on why it might not be the best fit.
But how about jsh files?
- I didn't researched how you could persist JShell, but seeing how it works like a black box, I don't have much hope
- You could just save the script and reexecute them, but executing cost a lot of time, so you are moving the problem of container amount into executin speed, which is a terrible trade
- You could do what wazei said, several sessions per container, but it's always possible for someone to crash the session, or at least right now. You could fix this by making so each session is its own process, which should solve most of the issues... but then if you have several process, it would cost a lot more ram and cpu, so it's still not good enough
- Something else ?
But note that this problem isn't currently a problem
we didn't reach a point where we had too many sessions yet
if you want to improve perfs, there is another area where you could do something : creating a container and executing the startup script costs a lot of time, so it would be great if we would have a buffer of one session, so we could just assign it, making so a /jshell eval would be much faster @stiff oak
Yeah, I agree to most points. However, for one shot operations, it could be considered because I believe not all operations necessarily need a state. But since it's not a problem currently, I could stop at it.
You mean having a set of pre-initialized containers which a startup script already executed right? Or I'm I missing smth?
Containers are deleted just after the operation in such case
yes
Alright, Please let me itemize the requirements:
- Pre-initialize some docker containers each with it's own identifying session id.
- For every new request for /eval we allocate a container from the buffer to the new session to make execution faster.
This is what I've gotten so far.
However I have some questions:
- What happens when the session expires for such containers, do you want to leave them operating.
- Does this apply or should it apply to single eval too.
The only difference between before and now, is that instead of creating a container when a new session is needed, you instead rename the buffer container to the one matching the session, and then init a new container with startup script, etc, that's all
Alright, what happens when the session expires?
nothing different, the container is deleted
Alright, it's clear, do I create an issue on that or would you instead or is it already created?
Check if there is an issue, if not, create one, I will complete it later
Alright would do that tomorrow, it's already bedtime here.
I've created an issue:
https://github.com/Together-Java/JShellPlaygroundBackend/issues/60
However, I think you may want to consider container reuse, which is essentially the same thing as earlier, only that this time, you invalidate the jshell session so that you don't have to restart another container for another session, however a mechanism like the amount of buffer containers at a time could also be implemented, like an array list, once a threshold is reached for containers in the buffer, new containers could be created and/or deleted.
It is too risky to reuse containers because users can rce
Yeah, true. So would you rather replace it with another container?
Dead sessions should have their containers deleted
Yeah, but if all containers are firstly used and then destroyed, if someone sends another /eval request it defaults to the previous implementation, so I mean when a container is used by a session, another could be re-created and added to the buffer.
The buffer should always contain one container
Alright
@sterile crest did you take into account that the GHA could create several pr if one isn't validated fast enough ?
also I can't edit the code of the pr since it's on your repo, or is it fine if I commit on your repo ?
Any advancement ?
Nope, I didn't account for that, but I did do a 15 min speed run lol
@bright lark I merged your pr
And can I commit on your fork ?
-_-
waz is smart, doesn't want to get blamed when this thing inevitably blows up 
ala's repo, ala's responsibility
@sterile crest can you rapidly review it please or @bright lark I wish to see it working before midnight
https://github.com/Together-Java/JShellPlaygroundBackend/pull/62
left a comment
alright, what do you think now
(I trust you for the command, I didn't tested it)
I pushed minors changes in the echoes
shouldnt you use --set-upstream ?
no - this only happens when the PR already exists
i.e. we didn't merge the new PR and it tried to raise a new one of the same update
ah so the if failed ?
if gh api repos/Together-Java/JShellPlaygroundBackend/branches/$branch_name >/dev/null 2>&1
well
let's test things one by one
does gh api repos/Together-Java/JShellPlaygroundBackend/branches/$branch_name works ?
nope lel
I added echo "A PR is already open for this release" but it didn't print out
up to you
seeing this kinda is ugly
but if we don't have any alerting on failed actions then sure
Yes but it should only happen if we don't merge the pr within one week
I'll add a pr for that if you want to work on it$
i dont wanna work on it
well approved
@sterile crest is this normal that nothing happened https://github.com/Together-Java/JShellPlaygroundBackend/actions/workflows/update-jshell-image-version.yaml
?
philosophically or?
if you think about it, for the majority of time since big bang, nothing really happened
so i would say nothing happening is quite normal
hello
im think im late
Did you even look at the code before merging the PR?
It very clearly stated every Friday at midnight
But you can manually kick it off since I added workflow dispatch
i dnt see the PR purpose
and it seems related to previous merged PR
the title says "update java version"
but i see in changes: "name: Auto-Update JShell Image version"

happy to know
BTW i'd like to raise awareness about the experience i got from the reviews done by ala it was really helpful
it was really helpful
no no this is insufficient
i mean it needs to be written on a book
2 junior developers helping each other improve, nice 
they are not
Yeah they are
not at all
i mean
some were significantly important and they implicitly bring values
Yeah important sure
