Cannot get repman to realize stable release after history rewritten (self hosted gitlab)

[josefsabl]

Hello, I have - what I believe is a bug - to report.

I had commit in repository tagged as 1.0.0 and repman was registering it as stable release. I rewritten the history and marked different commit with same tag. Now repman won't recognize the stable release.

I tripple checked the tag is indeed there.

Whats even more interesting: Now the package cannot be deleted and repman removes the webhook and then crashes into 500.

[akondas]

We will check this use case and let you know if it is actually a bug. Thanks for reporting 👍

[josefsabl]

Okay, so we decided to recreate the whole organization. So I tried to delete the original one and got.... Error 500.

Can you help us debug this? Our sys-admin was not able to find anything in repman logs.

[karniv00l]

Hi @josefsabl, can you double check the logs? They are located in repman's var/logs directory

[josefsabl]

I am sorry, I am polluting this thread with possibly unrelated stuff. But we have serious problems running repman and we constantly get various 500 responses. We did reset repman completely only to get more sorts of errors:

• After clean install and addition of user we were getting 500 on the homepage. Few docker restarts sorted this out.
• Now, I want to reset my password / and or create new user. Application says it sent an e-mail but it is never delivered (possibly problem with our infrastructure, but I don't know).
• Now, I want to add an existing user to the newly created organization and I, again, get 500. What is interesting, that symfony's exception page is displayed. I assume admin runs it in debug mode (which sort of helps us atm).

I am not familiar with contents of symfony's error page so I rather not post it here, but the error message is:

The stream or file "/app/var/log/prod.log" could not be opened in append mode: failed to open stream: Permission denied in /app/vendor/monolog/monolog/src/Monolog/Handler/StreamHandler.php (line 111)

We are running it in docker so I assume this may be problem with docker configuration. Are we doing anything wrong?

Thank you!

[josefsabl]

This problem seems to be on our side.

a) Turned out there were some incorrect permissons set for logs so parts of application could not write to them. b) Now we see that the real problem standing behind few of 500 was invalid certificate for the https communication.

Still researching it, will post more once we find out.

[josefsabl]

Okay, so we solved the 500. The problem was with sending e-mail as we are using our own mailserver which uses self-signed certificated. We had to enable debug mode for Symfony to see the error and by digging in the stack trace we managed to guess the problem was with sending e-mail.

We solved it like this.

MAILER_DSN=smtp://mx1.ourcompany.cz:25?verify_peer=0

This however is probably not related to the potential bug I was reporting in the first place. We just solved the "bug" by reinitializing everything.

So it is up to you if you close this :-)

Thank you very much!