GitLab CI: pipelines are triggered on behalf of my account

[Denis Konovalyenko]

For some reasons there happens the CI builds on behalf of my name when someone pushes to a branch in the main repository.

These are the recent "failed" emails content I have got for the aforementioned reason:

1.
Branch qa-with-codedtext-positions
Commit 97ef6bcb Fixed formatting.
Commit Author Yves
Pipeline #45275258 triggered by Denis Konovalyenko had 1 failed build.
2.
Branch integration-tests
Commit 64151962 Re-enable integration tests in CI
Commit Author Chase Tingley
Pipeline #45181345 triggered by Denis Konovalyenko had 1 failed build.
3.
Branch mihai_stream_exx
Commit b863120f Temporary streams
Commit Author Mihai Nita
Pipeline #43339296 triggered by Denis Konovalyenko had 1 failed build.

[Denis Konovalyenko]

@nmihai_2000 , I thought you had created a bot for triggering pipelines. Do you think there is something left to configure?

[Mihai Nita]

Yes, I've created the "okapiframework_robot" user.

It is a member of the Okapi project, with "owner" rights. But I could not make it trigger the builds. It looks like the "creator" of the project is the one showing as owner of the pipelines :-(

There seems to be some workarounds that people found. One is to remove all owners (including the creator) with the exception of the user you want to keep as "real owner", then add them back. The other option seems to be to transfer the project to that user, then transfer it back https://stackoverflow.com/questions/21579693/how-to-change-the-project-owner-in-gitlab

I was reluctant to try any of these... "if it's no broken, don't fix it" I don't get any emails, so for me is not broken ;-) (you might get all of them?)

But i'll give a try to those "tricks"...

[Mihai Nita]

I've tried to "Transfer project" (Settings --> General --> Advanced --> Transfer project)

I planned to "Select a new namespace" to send it to the robot user, then to "Okapi Framework" group.

And I got an error: "Project cannot be transferred, because tags are present in the container registry"

Then I tried to transfer to the "Okapi Framework" group. And I got "Transfer failed, please contact an admin"

Since I am in the middle of a workday, I would rather not tinker too much with it now. If I break something I don't have time to dig and fix it.

[Mihai Nita]

I've tried to transfer a project that I created to the "Okapi Framework" group, just in case it is the "creator" who must do the transfer.

And it failed with the same error ("Transfer failed, please contact an admin")

I will play a bit more with my test project later tonight.

[Mihai Nita]

It looks like in GitLab I can't delete owners, and I can't change their access level. I can do it for other level, like Maintainer (and probably below)

And it looks like I can't change a Maintainer to owner, and I can't invite someone as owner. But it was possible at some point... because most of us are "Owner"

Wonder if GitLab changed something... (the hosting service, not the server that one can download and host)

[Mihai Nita]

I wasn't able to change the users because all the users are handled in the "Okapiframework" group, not the "Okapi" project

I've temporary changed your permission to Guest, then back to Owner, to see if it changes the "ownership" of the "Okapi" project It was very fast (a few seconds), so you probably didn't notice. But if you get some emails about that, please don't panic :-)

[Mihai Nita]

About "Project cannot be transferred, because tags are present in the container registry":

https://gitlab.com/gitlab-org/gitlab-ce/issues/33301

[Denis Konovalyenko]

@nmihai_2000 , I really appreciate your efforts on this front!

As far as I understand, "the only way to move a project with containers in the registry is to first delete them all". I assume this would require some sort of a not so easy workaround. So, I am not totally against of getting the "failed build" emails and can wait for a good moment to address this without many struggles. But on the other hand, I am not sure if any of committers is getting a notification of such type (that was why the issue was created).

[Mihai Nita]

I've deleted the docker images, moved the project to okapiframework.robot, then moved it back to the okapi group. The submitted d04bb250 to bitbucket. The GitLab CI pipeline still belongs to you :-(

The only option I can think of is to use okapiframework.robot and make another project from scratch, then replace this one :-(

Or contact GitLab support...

From the various documentations I've read it is possible to change the "creator" of the project, but you need to be GitLab admin (like, the admin of the whole GitLab running server, which we are not, and we can't be)

[Mihai Nita]

I've created a new okapi project, then "did the swap" by renaming it with the old one. I've tested it a bit, and looks OKis. I will keep the old one around for a little bit, until it is all 100% good.

The Xliff toolkit build fails, so I could not check the xliff toolkit triggering the okapi one.

And it looks like we have the same problem with xliff toolkit, only that I am the owner :-(

[YvesS]

It looks like the XLIFF2 build error is from a problem the OASIS web site where the registry of extensions is stored. I'll ping them to ask about it.

[YvesS]

Maybe we need to change this test so it gives a big visual warning in the console if it does not passes, rather than a hard fail.

[Denis Konovalyenko]

Resolving this as I have not got any fail messages up to now.

Thanks, @nmihai_2000 !