#3526 tag requires admin permission for one task descendent
Closed: Dropped 2 years ago by dcantrell. Opened 2 years ago by dcantrell.

On RH internal Koji, if you look up task 47538529, there is one descendent task that produces an XML-RPC error. Task 47538750. In the web UI, it shows "ActionNotAllowed: tag requires admin permission" for Result. Talking to Koji over XML-RPC, I get a failure on getTaskResult for 47538750 telling me "tag requires admin permission (1004)".

I frequently use task numbers to look up build information and this is new to me. Looking at the web UI, it looks like all of the descendent tasks for 47538529 are for the different architectures while the one producing the XML-RPC error on getTaskResult is for noarch. Should there be a noarch build with other architectures?


There is no basically any problem. This error says that policy forbids developer to build in this target - build-related subtasks will be ok but result can't be published to target's tag which was forbidden by relengs.
tagBuild task is noarch as it doesn't need specific builder and can run anywhere - it is just a few API calls, but it doesn't do anything with the build artifacts.
If you look to any "build" task there is always one last "tagBuild" task - of course mostly successful. So in this case build exists, but if it will not be tagged to some tag it will get garbage-collected in few days (depending on GC policy).

Maybe it is confusing that that error is not meant for you - it is really the result of "tagBuild" task.

Metadata Update from @tkopecek:
- Custom field Size adjusted to None

2 years ago

That makes sense. So based on what you're saying, the tagBuild task when looking at task descendents is something I can safely ignore if I am only talking to Koji to collect build artifacts, right? At least for my case, that seems like an appropriate change I could make on my end and eliminate this error propagating up and falsely reporting to the user that a build does not exist or cannot be read.

Yes, you should stick to build's state (not task's state) which must be "COMPLETE". There are other cases when some subtask can fail but artifacts which were already completed are completely find (typically with chain-build where some builds can pass, some fail and overall task will fail as it was not able to fulfill all the goals)

OK, fixed on my end. Closing this issue. Thanks for the help.

Metadata Update from @dcantrell:
- Issue close_status updated to: Dropped
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata