mbien commented on PR #4921: URL: https://github.com/apache/netbeans/pull/4921#issuecomment-1315658541
> > would it help to upload the workspace for inspection and then diff (e.g with meld) the build before and after test? Maybe there is more wrong which could give clues what is going on there. > > Interesting -- how would I fetch that artifact ? scroll down in the summary page of the workflow run (which didn't set `ci:no-build`). It lists all artifacts. The regular workflow already uploads a shared artifact after the JDK 11 build which is a tar of the whole workspace. The cleanup job however removes that again if the build is green, if it isn't green it is kept. This allows restarts of failed jobs in the middle of the pipeline without starting from scratch. (and inspection of the workspace too) > 1. a bug in github action `setup-java@v3`. The action seems to unpack the JDK installation with improper timestamps: instead of leaving the file stats as they are stored in the archive, the unpacked contents is timestamped with the date/time of the action execution. If an application links to a `jar` inside a JDK, such as `tools.jar` for many NB modules, various up-to-date checks might fail, since the referenced JAR's time will be that of the JDK installation, not the time of the JAR's creation. interesting! We could setup all JDKs first, then use their env vars, since they all should set different vars. However, the regular workflow would build in a [primary job](https://github.com/apache/netbeans/blob/4a697ab128d7df8885a8479b5cc4212e6a56835e/.github/workflows/main.yml#L63) which produces the tar artifact as described above, then this test would run in a secondary job on a different JDK. This means each job would only setup one JDK. So this situation of setting up two JDKs in the same job should not occur outside of the job we did setup for this debugging PR here. (but we have other places which do that - so this is good to know) Also keep in mind that this is the first thing I tried. I simply added the LSP job to the existing pipeline. Interesting that the job intended for debugging purposes added another problem to the mix :) > 2\. the `CustomJavac` task used in `nbbuild` attempts to clean debris after `depend` ANT task - the depend task does not handle inner classes well, so `CustomJavac` cleans up inner classes that depend lefts behind, based on the enclosing class' presence. i was afraid that something like this could happen. All the hooks and wedges added a lot of non standard behavior over the years. I would suggest the following: lets extract all java changes from this PR into a fresh PR and get this PR in. Once its in, I update #4817 so that it is using a regular secondary job for the LSP testing - just like everything else. would this be ok? amazing work @sdedic, thanks a lot! -- 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
