You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@grails.apache.org by Carl Marcum <cm...@apache.org> on 2025/07/13 13:46:22 UTC
question about using verify scripts to verify a release during a vote
Hi All,
I was trying to go through the verification using the verify.sh script
during the vote.
I think I'm missing some setup or something.
I was running the verify script from my up-to-date clone of grails-core.
/./etc/bin/verify.sh v7.0.0-M5 ~/temp/verify/
and it seems to be failing during the verify-wrapper-distribution.sh
section:
/./grailsw -t shell create-app ShellApp/
Checking wrapper shell command ...
java.lang.ClassNotFoundException:
org.apache.grails.cli.DelegatingShellApplication
at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:593)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:534)
at java.base/java.lang.Class.forName(Class.java:513)
at grails.init.Start.main(Start.java:74)
❌ Verification failed. ❌
I do currently have M4 installed so I don't know if that has anything to
do with it or not.
I didn't have a lot of time during the M5 vote to get into it but
hopefully I can be ready for future ones.
Best regards,
Carl
Re: question about using verify scripts to verify a release during a vote
Posted by James Daugherty <jd...@apache.org>.
Hi Carl,
Thank you for clarifying! I'm glad the documentation was able to help too.
As for the verification failures, that script attempts to compare each jar file to a locally built copy vs the uploaded copy. We are unfortunately not 100% reproducible yet - but we are close! We produce some 300ish jars, and out of those jars we typically have 4-5 that aren't reproducible. When we spoke with ASF security, the build needs to be verifiable - reproducible is one way for this.
The current strategy is to take those 4 jars, extract each matching set, and then compare the decompiled byte code to ensure they're functionality equivalent.
FYI: the remaining differences can be explained by the following:
1. https://issues.apache.org/jira/browse/GROOVY-11689 - @Delegate causes method reordering
2. https://issues.apache.org/jira/browse/GROOVY-11715 - @DelegateTo has it's parameters reordered
3. Grails-forge has not updated to groovy 4 so the groovydoc doesn't have the fixes we made in https://issues.apache.org/jira/browse/GROOVY-11674 have not yet been applied
Once these are fixed, I am expecting our verification to be clean going forward.
-James
On 2025/07/16 22:55:38 Carl Marcum wrote:
> Hi James,
>
> I was running the script locally and I had set GRAILS_REPO_URL.
> I should have read the whole document before I started because I hadn't
> got to the Docker container :)
>
> Now I've tried it and seemed to go well except for the mention of
> verification failed shown below.
> Is that typical?
>
> ---
>
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> Gradle build daemon disappeared unexpectedly (it may have been killed or
> may have crashed)
>
> * Try:
> > Run with --stacktrace option to get the stack trace.
> > Run with --info or --debug option to get more log output.
> > Run with --scan to get full insights.
> > Get more help at https://help.gradle.org.
> ❌ Verification failed. ❌
> ❌ Verification failed. ❌
> ✅ Reproducible Build Verified
> Be sure to do the following:
> ☑️ Set the override repo: 'export
> GRAILS_REPO_URL=https://repository.apache.org/content/groups/staging'
> ☑️ Run the wrapper ShellApp: cd
> /home/groovy/grails-verify/apache-grails-wrapper-7.0.0-M5-incubating-bin/ShellApp
> && ./gradlew bootRun --init-script ~/grails-verify/custom-repos.gradle
> ☑️ Run the wrapper ForgeApp: cd
> /home/groovy/grails-verify/apache-grails-wrapper-7.0.0-M5-incubating-bin/ForgeApp
> && ./gradlew bootRun --init-script ~/grails-verify/custom-repos.gradle
> ☑️ Run the cli ShellApp: cd
> /home/groovy/grails-verify/apache-grails-7.0.0-M5-incubating-bin/bin/ShellApp
> && ./gradlew bootRun --init-script ~/grails-verify/custom-repos.gradle
> ☑️ Run the cli ForgeApp: cd
> /home/groovy/grails-verify/apache-grails-7.0.0-M5-incubating-bin/bin/ForgeApp
> && ./gradlew bootRun --init-script ~/grails-verify/custom-repos.gradle
> ☑️ Add the local repos to the application and then run the shell cli
> from one of the applications and ensure all commands show as expected -
> pay attention to the scaffolding ones since they are dynamically loaded
> ✅✅✅ Verification finished, see above instructions for remaining manual
> testing.
> groovy@6b743c022c7a:~/grails-verify$
>
> ---
>
> I'll continue working through the remaining steps so I have it for next
> time.
>
> BTW, congratulations All on the M5 milestone!
>
> Best regards,
> Carl
>
> On 7/13/25 12:11 PM, James Daugherty wrote:
> > Hi Carl,
> >
> > First, thank you for taking a look at the release!
> >
> > Are you running the very script locally on your machine or in the docker container command we provide in the RELEASE.md? Also, are you running those commands manually or is the verify script? If you're running them manually, you need to point at the staging repo so the wrapper downloads the file: export GRAILS_REPO_URL=https://repository.apache.org/content/groups/staging
> >
> > Concerning this specific issue, we did discover that the wrapper can fail in certain circumstances, specifically around these temporary states.https://github.com/apache/grails-core/pull/14896 is the PR that fixes it for the next release - I didn't feel it was important enough to cancel the release given the scope of changes over the past month (this is a milestone so we expect issues like this to be found) & because the issue only affects these transitives states / snapshots.
> >
> > -James
> >
> > On 2025/07/13 13:46:22 Carl Marcum wrote:
> >> Hi All,
> >>
> >> I was trying to go through the verification using the verify.sh script
> >> during the vote.
> >> I think I'm missing some setup or something.
> >>
> >> I was running the verify script from my up-to-date clone of grails-core.
> >>
> >> /./etc/bin/verify.sh v7.0.0-M5 ~/temp/verify/
> >>
> >> and it seems to be failing during the verify-wrapper-distribution.sh
> >> section:
> >>
> >> /./grailsw -t shell create-app ShellApp/
> >>
> >> Checking wrapper shell command ...
> >> java.lang.ClassNotFoundException:
> >> org.apache.grails.cli.DelegatingShellApplication
> >> at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445)
> >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:593)
> >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
> >> at java.base/java.lang.Class.forName0(Native Method)
> >> at java.base/java.lang.Class.forName(Class.java:534)
> >> at java.base/java.lang.Class.forName(Class.java:513)
> >> at grails.init.Start.main(Start.java:74)
> >> ❌ Verification failed. ❌
> >>
> >> I do currently have M4 installed so I don't know if that has anything to
> >> do with it or not.
> >>
> >> I didn't have a lot of time during the M5 vote to get into it but
> >> hopefully I can be ready for future ones.
> >>
> >> Best regards,
> >>
> >> Carl
> >>
Re: question about using verify scripts to verify a release during a vote
Posted by Carl Marcum <cm...@apache.org>.
Hi James,
I was running the script locally and I had set GRAILS_REPO_URL.
I should have read the whole document before I started because I hadn't
got to the Docker container :)
Now I've tried it and seemed to go well except for the mention of
verification failed shown below.
Is that typical?
---
FAILURE: Build failed with an exception.
* What went wrong:
Gradle build daemon disappeared unexpectedly (it may have been killed or
may have crashed)
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.
❌ Verification failed. ❌
❌ Verification failed. ❌
✅ Reproducible Build Verified
Be sure to do the following:
☑️ Set the override repo: 'export
GRAILS_REPO_URL=https://repository.apache.org/content/groups/staging'
☑️ Run the wrapper ShellApp: cd
/home/groovy/grails-verify/apache-grails-wrapper-7.0.0-M5-incubating-bin/ShellApp
&& ./gradlew bootRun --init-script ~/grails-verify/custom-repos.gradle
☑️ Run the wrapper ForgeApp: cd
/home/groovy/grails-verify/apache-grails-wrapper-7.0.0-M5-incubating-bin/ForgeApp
&& ./gradlew bootRun --init-script ~/grails-verify/custom-repos.gradle
☑️ Run the cli ShellApp: cd
/home/groovy/grails-verify/apache-grails-7.0.0-M5-incubating-bin/bin/ShellApp
&& ./gradlew bootRun --init-script ~/grails-verify/custom-repos.gradle
☑️ Run the cli ForgeApp: cd
/home/groovy/grails-verify/apache-grails-7.0.0-M5-incubating-bin/bin/ForgeApp
&& ./gradlew bootRun --init-script ~/grails-verify/custom-repos.gradle
☑️ Add the local repos to the application and then run the shell cli
from one of the applications and ensure all commands show as expected -
pay attention to the scaffolding ones since they are dynamically loaded
✅✅✅ Verification finished, see above instructions for remaining manual
testing.
groovy@6b743c022c7a:~/grails-verify$
---
I'll continue working through the remaining steps so I have it for next
time.
BTW, congratulations All on the M5 milestone!
Best regards,
Carl
On 7/13/25 12:11 PM, James Daugherty wrote:
> Hi Carl,
>
> First, thank you for taking a look at the release!
>
> Are you running the very script locally on your machine or in the docker container command we provide in the RELEASE.md? Also, are you running those commands manually or is the verify script? If you're running them manually, you need to point at the staging repo so the wrapper downloads the file: export GRAILS_REPO_URL=https://repository.apache.org/content/groups/staging
>
> Concerning this specific issue, we did discover that the wrapper can fail in certain circumstances, specifically around these temporary states.https://github.com/apache/grails-core/pull/14896 is the PR that fixes it for the next release - I didn't feel it was important enough to cancel the release given the scope of changes over the past month (this is a milestone so we expect issues like this to be found) & because the issue only affects these transitives states / snapshots.
>
> -James
>
> On 2025/07/13 13:46:22 Carl Marcum wrote:
>> Hi All,
>>
>> I was trying to go through the verification using the verify.sh script
>> during the vote.
>> I think I'm missing some setup or something.
>>
>> I was running the verify script from my up-to-date clone of grails-core.
>>
>> /./etc/bin/verify.sh v7.0.0-M5 ~/temp/verify/
>>
>> and it seems to be failing during the verify-wrapper-distribution.sh
>> section:
>>
>> /./grailsw -t shell create-app ShellApp/
>>
>> Checking wrapper shell command ...
>> java.lang.ClassNotFoundException:
>> org.apache.grails.cli.DelegatingShellApplication
>> at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445)
>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:593)
>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
>> at java.base/java.lang.Class.forName0(Native Method)
>> at java.base/java.lang.Class.forName(Class.java:534)
>> at java.base/java.lang.Class.forName(Class.java:513)
>> at grails.init.Start.main(Start.java:74)
>> ❌ Verification failed. ❌
>>
>> I do currently have M4 installed so I don't know if that has anything to
>> do with it or not.
>>
>> I didn't have a lot of time during the M5 vote to get into it but
>> hopefully I can be ready for future ones.
>>
>> Best regards,
>>
>> Carl
>>
Re: question about using verify scripts to verify a release during a vote
Posted by James Daugherty <jd...@apache.org>.
Hi Carl,
First, thank you for taking a look at the release!
Are you running the very script locally on your machine or in the docker container command we provide in the RELEASE.md? Also, are you running those commands manually or is the verify script? If you're running them manually, you need to point at the staging repo so the wrapper downloads the file: export GRAILS_REPO_URL=https://repository.apache.org/content/groups/staging
Concerning this specific issue, we did discover that the wrapper can fail in certain circumstances, specifically around these temporary states. https://github.com/apache/grails-core/pull/14896 is the PR that fixes it for the next release - I didn't feel it was important enough to cancel the release given the scope of changes over the past month (this is a milestone so we expect issues like this to be found) & because the issue only affects these transitives states / snapshots.
-James
On 2025/07/13 13:46:22 Carl Marcum wrote:
> Hi All,
>
> I was trying to go through the verification using the verify.sh script
> during the vote.
> I think I'm missing some setup or something.
>
> I was running the verify script from my up-to-date clone of grails-core.
>
> /./etc/bin/verify.sh v7.0.0-M5 ~/temp/verify/
>
> and it seems to be failing during the verify-wrapper-distribution.sh
> section:
>
> /./grailsw -t shell create-app ShellApp/
>
> Checking wrapper shell command ...
> java.lang.ClassNotFoundException:
> org.apache.grails.cli.DelegatingShellApplication
> at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:593)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:534)
> at java.base/java.lang.Class.forName(Class.java:513)
> at grails.init.Start.main(Start.java:74)
> ❌ Verification failed. ❌
>
> I do currently have M4 installed so I don't know if that has anything to
> do with it or not.
>
> I didn't have a lot of time during the M5 vote to get into it but
> hopefully I can be ready for future ones.
>
> Best regards,
>
> Carl
>