RTC V3.0 - Personal Dependency Build in Pending state
I have a user who requested a personal dependency build and it just stays in a pending state. The bfagent is running and processes other build requests. I looked at the /u/jazz/logs/ccm and jts and was unable to see any specific problem. I also looked at the job log for the repository server and again nothing related to the pending build. This is for RTC n z/OS.
Where else can I look to determine why this specific user's personal buld requests stay in pending. This user is able to request non-personal (stream) builds and they rin ok.
Where else can I look to determine why this specific user's personal buld requests stay in pending. This user is able to request non-personal (stream) builds and they rin ok.
3 answers
Are you using Build Agent Authentication Override for submitting your personal build?
Yes - we finally found out basically by accident what the problem was. The user's zOS password had expired. The user tried to log on to zOS to look around and discovered that her password had expired.
My question is - in a case like that where can you look to get an idea of why this users personal builds are staying in the pending state?
The way it currently works is that if it fails to contact the first associated agent, it moves on to the next. If none are able to be contacted, then the build will be left in the pending state. This is consistent with the way other builds like JBE-based ones work: if no engine picks up the build, it's left in the queue.
However, I agree that the feedback in this case could definitely be improved, especially since the server has knowledge of the various attempts to contact the agents (unlike the JBE case). One approach would be to log each attempt in the build log, then if none of the agents can be contacted, fail the build (with the log attached, as normal). The engine item could also be put in a warning state if there's an authentication or other error.
I've opened 141292: Poor feedback when build agent cannot be contacted due to auth failure to track this further, and have subscribed you.
However, I agree that the feedback in this case could definitely be improved, especially since the server has knowledge of the various attempts to contact the agents (unlike the JBE case). One approach would be to log each attempt in the build log, then if none of the agents can be contacted, fail the build (with the log attached, as normal). The engine item could also be put in a warning state if there's an authentication or other error.
I've opened 141292: Poor feedback when build agent cannot be contacted due to auth failure to track this further, and have subscribed you.