Personal Build errors - Argument components must not be empty
I have a Personal Build build definition in RTC, which allows myself and other developers on my project to issue their own personal builds (from their local workspaces).
There is a common user id/password that is used for all personal builds (it happens to be my id). To complicate things, this is a ZSeries build (RTC for z).
These builds have been working for all of my developers for some time. I change the password file on the Z build machine every 90 days (as required), and the builds continue to work. And, in fact, I myself can issue a personal build, as well as any of my developers who haven't created the local workspace recently.
For my developers that have recently created the workspace, their personal builds are failing. There was initially an authentication error based on my user ID, indicating that the workspace could not be accessed. Apparently, something has changed in RTC (according to my RTC expert) whereby workspaces are created with Private, rather then Public, visibility by default. When that Visibility was changed to Public, my developer was greeted with the build error reported in the summary:
...
* Caused by: java.lang.IllegalArgumentException: Argument components must not be empty
* at com.ibm.teamz.fileagent.Zutility.zloadOnMVS(Zutility.java:363)
* at com.ibm.teamz.fileagent.Zutility.zload2(Zutility.java:255)
* at com.ibm.teamz.fileagent.internal.operations.LoadWorkspaceOperation.execute(LoadWorkspaceOperation.java:66)
...
At this point, my RTC expert suggested that there may be other authorization changes that are needed (more than simply at the workspace level). He suggested that the Component must also be public -- but the component (I am the owner of the Component) is already set to public access.
Any ideas on what may be happening? I need to get my development team back to performing personal builds...
Bill
There is a common user id/password that is used for all personal builds (it happens to be my id). To complicate things, this is a ZSeries build (RTC for z).
These builds have been working for all of my developers for some time. I change the password file on the Z build machine every 90 days (as required), and the builds continue to work. And, in fact, I myself can issue a personal build, as well as any of my developers who haven't created the local workspace recently.
For my developers that have recently created the workspace, their personal builds are failing. There was initially an authentication error based on my user ID, indicating that the workspace could not be accessed. Apparently, something has changed in RTC (according to my RTC expert) whereby workspaces are created with Private, rather then Public, visibility by default. When that Visibility was changed to Public, my developer was greeted with the build error reported in the summary:
...
* Caused by: java.lang.IllegalArgumentException: Argument components must not be empty
* at com.ibm.teamz.fileagent.Zutility.zloadOnMVS(Zutility.java:363)
* at com.ibm.teamz.fileagent.Zutility.zload2(Zutility.java:255)
* at com.ibm.teamz.fileagent.internal.operations.LoadWorkspaceOperation.execute(LoadWorkspaceOperation.java:66)
...
At this point, my RTC expert suggested that there may be other authorization changes that are needed (more than simply at the workspace level). He suggested that the Component must also be public -- but the component (I am the owner of the Component) is already set to public access.
Any ideas on what may be happening? I need to get my development team back to performing personal builds...
Bill
One answer
Hi Bill,
I'd be inclined to say that there's still an issue with the visibility of the component. The first thing I'd try to figure out what might be going on is to use the RTC SCM CLI from one of your distributed workstations, to see if it's able to see the components in question. Try running something like this:
./scm list components -u builder -r https://your.server:9443/ccm "Repository Workspace Name"
A couple notes:
- Be sure to specify the RTC username of your build account (as specified in your startbfa.sh script) following the -u option, not the username of the user requesting the build.
- Change "Repository Workspace Name" to the name of a repository workspace that was used during a personal build that failed in this way.
If that command is able to correctly list the component inside the repository workspace, there's something strange going on on the build side of things that we'll need to investigate. However, if that command shows the workspace without the component underneath it, it means that your builder user account is still unable to see the component, and we need to focus on figuring out why.
It might also be interesting to compare the output of that command when it's run against a repository workspace that results in a failing personal build versus the output when it's run against a repository workspace used in a successful personal build.
I'd be inclined to say that there's still an issue with the visibility of the component. The first thing I'd try to figure out what might be going on is to use the RTC SCM CLI from one of your distributed workstations, to see if it's able to see the components in question. Try running something like this:
./scm list components -u builder -r https://your.server:9443/ccm "Repository Workspace Name"
A couple notes:
- Be sure to specify the RTC username of your build account (as specified in your startbfa.sh script) following the -u option, not the username of the user requesting the build.
- Change "Repository Workspace Name" to the name of a repository workspace that was used during a personal build that failed in this way.
If that command is able to correctly list the component inside the repository workspace, there's something strange going on on the build side of things that we'll need to investigate. However, if that command shows the workspace without the component underneath it, it means that your builder user account is still unable to see the component, and we need to focus on figuring out why.
It might also be interesting to compare the output of that command when it's run against a repository workspace that results in a failing personal build versus the output when it's run against a repository workspace used in a successful personal build.