mbien commented on PR #5609:
URL: https://github.com/apache/netbeans/pull/5609#issuecomment-1484233047

   > @mbien could you check if that addresses some of you concerns? We can 
discuss whether nbjavac is really a good idea, but at this point in time it is 
an integral part of the core of Java editing in NetBeans and I think it might 
help catching bugs.
   
   @matthiasblaesing github workflows can't really trigger on particular labels 
unfortunately. I believe the easiest way to build using nb-javac when the label 
is set would be to simply paste the proposed job into the main.yaml.
   
   copy this:
   
https://github.com/matthiasblaesing/netbeans/blob/623a396c8ed341834d080eb7f4a1d2aa487e6b87/.github/workflows/nb-javac.yml#L6-L28
   (rename `linux` to `nb-javac` for example, since that would be the job 
handle)
   
   and paste it somewhere below `base-build` in main.yaml
   
   having it as separate workflow is fine in theory, but it would startup and 
do nothing most of the time and create empty runs on that list:
   https://github.com/apache/netbeans/actions
   
   i would also recommend to remove the `|| github.event_name != 
'pull_request'` and `ci:all-tests` conditions so that it doesn't have to run 
outside of PRs which set the label.
   
   The cache should be used too so that we don't DDoS someone:
   ```
     - name: Restore Cache
       uses: actions/cache/restore@v3
       with:
         path: ~/.hgexternalcache
         key: ${{ runner.os }}-${{ hashFiles('*/external/binaries-list', 
'*/*/external/binaries-list') }}
         restore-keys: ${{ runner.os }}-
   ```
   this should only restore the cache based on hash match or prefix as fallback 
but never store, other then that it works analog to the base-build job. (never 
used the restore action before, its a fairly new feature they added earlier 
this year)
   
   For the record: I have nothing against nb-javac and do agree it is an 
important dependency of the java editor right now. However, the testing of 
nb-javac should be done in the nb-javac repository, not in a downstream 
repository in my opinion. What should we even do if that one job is red? Not 
merge a PR? Wait for nb-javac to fix something, upload a binary to central and 
test again?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Reply via email to