Automatically suggest updates based on JDT-LS Java language support. #3402
Conversation
Checks for JDK updates, issues PR
Queries https://ci.eclipse.org/ls/job/jdt-ls-master/lastCompletedBuild/testReport/ for status on latest JDK
Create check_and_update_jdk.py
To manually trigger a GitHub Action, you need to add a `workflow_dispatch` event to your workflow file. This event allows you to trigger the workflow manually using the GitHub Actions web interface or the GitHub API¹. After adding the `workflow_dispatch` event, you can manually trigger your GitHub Action by going to the Actions tab of your repository and clicking on the "Run workflow" button¹. Please note that to trigger the `workflow_dispatch` event, your workflow must be in the default branch¹. If your workflow is on a different branch, you might need to merge it into the default branch first. Also, write access to the repository is required to perform these steps¹.. Sources: (1) Manually running a workflow - GitHub Docs. https://docs.github.com/en/actions/using-workflows/manually-running-a-workflow. (2) Triggering a workflow - GitHub Docs. https://docs.github.com/en/actions/using-workflows/triggering-a-workflow. (3) Manual Trigger In GitHub Actions - Knoldus Blogs. https://blog.knoldus.com/manual-trigger-in-github-actions/. (4) Configuring Manual Triggers In GitHub Actions With ... - Build5Nines. https://build5nines.com/configuring-manual-triggers-in-github-actions-with-workflow_dispatch/. (5) Manually Trigger a GitHub Action with workflow_dispatch. https://dev.to/this-is-learning/manually-trigger-a-github-action-with-workflowdispatch-3mga.
No need to emit an error
Move disk write conditional on updating the JDK version.
|
I have tested this action on my fork. I believe
This setting can be found in a repository's settings under |
Tests are `PASSED`, not `SUCCESS`
Use gh instead of 3rd party PR action
Update regex logic to replace `java.configuration.runtimes` example as well:
```json
{
"name": "JavaSE-21",
"path": "/path/to/jdk-21",
"default": true
},
```
Correct minor errors: - In the `Branch and push changes` step, had `with` keyword instead of the `run` keyword leftover from previous implementation. - In the same step, changed the `::set-env` command to set the `latest_jdk` environment variable to use the `env` keyword instead, as described in this [guide][1]. This command is deprecated and will be removed soon. [1] https://docs.github.com/en/actions
Utilize shebang line at the top.
Do we need JDT Core to add this as a feature? It seemed to me that we can track the tests that are already published in the CI:
The last test method and endpoint is variable with the |
|
No, I just wanted to explain that the changes that go into JDT-LS that are tracked in the script by certain test cases depend on JDT Core supporting that particular Java version. |
Forgot how gfm links work 😅
Changing comment to reflect PR technique
Prevent the workflow from running if an equivalent pull request (PR) has already been issued by checking for a PR with the same title
> Since [b1d0831](redhat-developer@b1d0831) , we took advantage of [settings groups](https://code.visualstudio.com/docs/getstarted/settings#_settings-groups), which made the configuration object contain a list of the groups, each containing a properties objects.
Clean up previous `latest_jdk.txt` records prior to checking for its existence to not get false positives.
rgrunber
changed the title
|
@mavaddat , Just a heads-up the script didn't work for eclipse-jdtls/eclipse.jdt.ls#3111. Apparently the regex won't catch just Also, not sure why I didn't catch this before, but the checks in the script, from the table above, that confirm JDT-LS has new version support and that reference "Sealed" should not be used. Sealed classes were finalized in Java 17 but for some reason it probably looked like their version should continue to be bumped. Probably just the 3 importer related tests are enough. |
Right. I see why. I did not know that major releases could have no minor semver part. I have corrected this in the 49e3b48 commit.
Oh, that's too bad. I kind of liked the loop I created to check for those tests. 😅 I have removed them nevertheless on 49e3b48. |
|
Yeah that format looked odd to me as well, but feel free to propose a PR for it. It also published this a few hours ago.. I suspect because of : at #3547 (hide whitespace makes the change easier to understand). I guess we should have our package.json be properly formatted to have the changes easier to see in the future. |
I created this action and script by closely scrutinizing the logic of the pull requests for this and the eclipse-jdtls/eclipse.jdt.ls repos:
This led me to generalize the workflow using the very convenient API endpoints for the eclipse-jdtls CI pipeline.
I tested the scripts on my local machine, but of course, the resources and tokens on the runner are different. Needs testing.