Create an issue on the project when pushing fails

[astellingwerf]

What would you like Renovate to be able to do?

GitLab allows setting Push rules on projects. With it, one can block pushes for branches not matching a certain naming convention (regex), or require or block certain commit messages. If those settings are not Renovate-ready, the process will end with an error.

In my situation, I control the Renovate pipeline, but I do not have access to (all) projects it runs against. Often, I don't even know who owns them. I can see the Renovate logs, but the users cannot.

I'd suggest that Renovate would create a "Action Required: Fix Renovate Configuration" issue on the project that displays the push error it experienced

If you have any ideas on how this should be implemented, please tell us here.

No, sorry.

Is this a feature you are interested in implementing yourself?

Maybe

[astellingwerf]

If the push of the onboarding branch fails, maybe the issue should give some explicit guidance on how to manually onboard Renovate, possibly already either pointing to properties to tweak the behaviour, or demonstrating the expected behavior of Renovate, so that the admin can tweak the settings of the platform/repo.

[hasanwhitesource]

@astellingwerf To be clear you are suggesting to create an issue in the Gitlab issues board for the repo if there were problems with the onboarding pr ?

[astellingwerf]

Not just the Onboarding PR, @hasanwhitesource, though that would typically be the first instance where we run into the blocking push rules. But the same issue might occur for normal Update PRs.

[hasanwhitesource]

@astellingwerf Could you please provide an example of a push rule that you have and expected result ? Also can you clarify "If those settings are not Renovate-ready" part more

[astellingwerf]

You may best look at this page, and the "Validate commit messages" and "Validate branch names" sections in particular. That's a typical example: branch names must be a JIRA ticket ID, so it's not expecting renovate/configure or renovate/spring-boot. One might also put similar requirements on the commit messages, or enforcing semantic commits.

I would expect an issue to be created, along the lines of:

Renovate attempted to create a (onboarding)? PR (for dependency spring-boot)?, but it encountered the following error while pushing to the branch renovate/something:

To https://gitlab.otxlab.net/dctm/poc/documentum-search.git
!\trefs/heads/renovate/configure:refs/heads/renovate/configure\t[remote rejected] (pre-receive hook declined)
Done
Pushing to https://gitlab.otxlab.net/dctm/poc/documentum-search.git
POST git-receive-pack (584 bytes)
remote: GitLab: Commit message does not follow the pattern '^(Update .*$|Pin .*$|Merge branch .*$|[A-Z]{1,10}\\-\\d{1,10}:).{0,100}$'
error: failed to push some refs to 'https://gitlab.otxlab.net/dctm/poc/documentum-search.git'

Push rules

This may have been caused by push rules. In order to allow the push request, update your projects Push rules for your project. Renovate is configured to push with commits following ?these conventions? to branches adhering to ?these patterns?. Read these pages for more info.

Onboarding

If the branch cannot be created to onboard, there is no way to configure the branch name conventions either. To manually onboard, create a file renovate.json with the following content, and merge it to the main branch.

?content that would be in the PR?

You can then set ?these properties? to tweak the branch name conventions to match the projects push rules.

[hasanwhitesource]

@viceice You think we should only create an issue when pushing fails incase of a push rule ?

[viceice]

i think it can be opened on any non-transient error.

we should never open an issue for transfer errors, which could be temporary.

[hasanwhitesource]

@viceice So to make sure I understand we should only open an issue incase of a push rule violation since this error will be constant unless the user changes according to the push rule.

[astellingwerf]

I'm not sure that we can definitively determine that the push fails because of a Gitlab Push rule. It seems that they've implemented it as a pre-receive hook. I imagine: If the push fails for non I/O exception reason, create an issue, and auto-close it when the push succeeds?

Caveat: Heroku does the build and deploy as part of a push hook If the build/test/deploy fails, the push gets rejected. Do we want to create issues for that? Do we maybe need a repo level property that could prevent push issue creation?

[hasanwhitesource]

@astellingwerf yes I was looking into how we can determine if the push fails cause of a push rule. I see we already have a catch for ExternalHostError in repository/update which in this case where it fails, after that I was thinking of examining the error message to determine if the error is indeed a push rule error. What do you think ?

[nabeelsaabna]

hasanwhitesource: we should only open an issue incase of a push rule violation

one of the reasons, but not the only reason to open an issue

astellingwerf: I'm not sure that we can definitively determine that the push fails because of a Gitlab Push rule

also need to consider that error handling is not platform specific

[hasanwhitesource]

@astellingwerf Would it be better to agree on an issue template to open incase of any external error that could be helpful to users which is not specific to a Gitlab push rule?

[astellingwerf]

Yes, that does make sense, @hasanwhitesource. Maybe keep it simple in the Issue, and clearly refer to richer documentation pages.

[hasanwhitesource]

@astellingwerf since the fail for this will be caused by an external error what kind of documentation from renovate would be helpful or relevant to show the user ? @HonkingGoose Can you maybe offer some insights on the issue template to be shown for this case?

[nabeelsaabna]

in case you can't know if the root cause is "push rule violation", then the message should be generic for all platforms

[HonkingGoose]

@HonkingGoose Can you maybe offer some insights on the issue template to be shown for this case?

@hasanwhitesource I don't know about this. Maybe @rarkins has some ideas?

[rarkins]

Are we sure it needs to be a new issue and not just the existing configuration warning one?

[cschlesselmann]

astellingwerf since the fail for this will be caused by an external error what kind of documentation from renovate would be helpful or relevant to show the user ?

Why don't you just include the message field from the error in the issue? I think that would prove helpful for any errors that might occur

for example the log entry is:

{
    "name": "renovate",
    "level": 50,
    "logContext": "UJkZZPlFvB6L6gz4buNtG",
    "repository": "example/repository",
    "err": {
        "task": {
            "commands": [
                "push",
                "origin",
                "renovate/configure:renovate/configure",
                "--force-with-lease",
                "-u",
                "--no-verify",
                "--verbose",
                "--porcelain"
            ],
            "format": "utf-8",
            "parser": "[function]"
        },
        "message": "To https://gitlab.example.org/example/repository.git\n!\trefs/heads/renovate/configure:refs/heads/renovate/configure\t[remote rejected] (pre-receive hook declined)\nDone\nPushing to https://gitlab.example.org/example/repository.git\nPOST git-receive-pack (535 bytes)\nremote: GitLab: Branch name does not follow the pattern '^some-regex$'\nerror: failed to push some refs to 'https://gitlab.example.org/example/repository.git'\n",
        "stack": "......"
    },
    "msg": "Repository has unknown error"
}

The issue would include

To https://gitlab.example.org/example/repository.git
!	refs/heads/renovate/configure:refs/heads/renovate/configure	[remote rejected] (pre-receive hook declined)
Done
Pushing to https://gitlab.example.org/example/repository.git
POST git-receive-pack (535 bytes)
remote: GitLab: Branch name does not follow the pattern '^some-regex$'
error: failed to push some refs to 'https://gitlab.example.org/example/repository.git'