tibdex / autorebase Goto Github PK

I was really excited when I found this app as I thought that it would be a perfect helper for the workflow that we employ on a number of repositories.

However, the first attempt at using it, didn't work as I would have expected:

cake-build/website#609 (comment)

However, I thought that the issue here was due to the fact that the PR was coming from the develop branch on the fork, rather than a branch on the fork. However, I have just tried again with a branch on a fork, and I got the same result:

cake-build/website#635 (comment)

Are my expectations of what this app can do wrong?

Normally, in this situation, the steps that I would follow manually would be:

git clone https://github.com/gep13/website.git
cd website
git remote add upstream  https://github.com/cake-build/website.git
git checkout eazfuscator
git fetch upstream
git rebase upstream/develop
git push -f

And I was hoping that this app would be able to help with this. Is my expectations incorrect?

Thx for offering this service and github app!

Although I scanned the Readme multiple times it is not clear to me how to support the following use case:
We switched off merging PRs but we let developer pick to squash'n'merge or rebase. The common default is squash'n'merge, but adding the autorebase label always rebases.
How to let the app know that for this specific PR I want it to be squash'n'merged?
Could that be done with another label autosquash?
Or can something be configured or are there more comment options?

I hope I was able to phrase my question n an understandable manner.

Best Christian

I know that right now, this GitHub app is free, and at the current level of use it is very cheap to run on Microsoft Lambda.

After you have done calculations based on your expected level of use, you should write in the README some promises or explicit non-promises about whether this app will cost money and whether it will stay running. You can also assure users that even if the hosted GitHub app shut down, they could host it themselves, use an alternative, or go back to running Git commands manually.

It could of course also be an issue with Jira, but are there any webhooksnot triggered that would be triggered when landing something by clickng the buttons?

With that information I would cross post the issue for Jira (cloud) and cross link the two issues.

Thx in advance

I installed the app, and gave permission to our private repo. But when I add the label autorebase, it doesn't trigger the bot. I am able to see the bot autorebase in the author list. Should we do something additional like adding the webhook manually?

Another thing is that our target branch is staging, not master. Does this cause the problem?

I deployed the autorebase app on Zeit.

I receive multiple error concerning GitHub Rate Limit: HttpError: API rate limit exceeded for installation ID XXXX. I'm unsure what steps I need to take to resolve this problem.

The public instance has been shutdown:

• It went way over the Zeit Free Plan.
• Focus has shifted to the development of Autosquash, the successor of Autorebase. More explanation here.

See celery/celery#5529 (comment).
It's not very clear from the error what went wrong exactly.

I'm trying to deploy autorebase for my organisation. I trying to configure the CI for the project.

I'm having trouble executing the test locally. I figured mostly everything that goes in the .env, but always end up with the following error: HttpError: Resource not accessible by integration

Hello,

Autorebase looks verycool, but when we merge we deploy, so i don't want merging to be done by this tool.

How can I use only the autorebase feature ?

Looking at the source code and at this particular flag, I am not sure it works as expecting.

Your process to manage concurrency is:

1. flag the PR with autorebasing using the call addLabels
2. execute your operation
3. remove the flag

Yet it is unclear if addLabels fails if the label is already present. If not, you could end up having the multiple executors executing step 1.

An alternative would be to:

1. add the label autorebasing
2. remove the label autorebase, using removeLabel
3. execute the operation
4. restore the label autorebase
5. remove the label autorebasing

As removing a label returns a 404 when the label is not present, one and only one process can remove the label autorebase and perform the rebase operation.
One advantage is that the PR cannot be found anymore when listig the candidates.

Again, if addLabels has a way to signal that labels are already present, this is not an issue.

Hi,

We've been trying the autorebase bot but witnessing some behaviour that's not clear to us.

When we add the autorebase label to a PR, the bot will rebase the branch when it gets out of date, and then sometimes remove the label. Is this by design?

We've also seen the bot remove the label, rebase the branch, then add the label again. Not sure why it's doing this!

Hi!

First of all, thanks a lot for autorebase, it is a really useful project.

Would it be possible to configure autorebase to change its final rebase behaviour?

Now, when a PR has the "autorebase" tag, and the build status is green, autorebase merges the PR with the github api by using the rebase method.

I would like autorebase to do something like: git rebase + git merge --no-ff, to get something like this git history:

I have tried changing autorebase.ts to:

  await octokit.pulls.merge({
    merge_method: "merge",

and it does work, to some extend. autorebase merges the PR when the build is green, but it does not make a rebase first. It does not "detect" that the master branch has evolved and that before merging it should make another rebase.

Would it be possible to make something like this? I am not fluent at all at typescript, but if you give me some hints about what would be needed I can try to develop it.

Thanks a lot!!

In this section:

• Provide a comparison table with columns such as "rebase or merge" and "tests on latest before merging".
• Mention in the description of Bors that it is better for projects with a high rate of incoming PRs, since the time to run the builds is logarithmic with the number of PRs.

I'm currently using autorebase in one of my projects building with CircleCI.

The problem is that autorebase (through its dependencies) creates temporary branch in order to rebase. During the build, Circle tries to checkout this branch, and fails because it has been already removed.

My point is : can we imagine a workaround which lets us to choose the temporary branch name in order to be able to ignore it on CI tools ?

Today, temporary branch name seems to be based on these two lines :

• https://github.com/tibdex/github-cherry-pick/blob/master/src/index.js#L256
• https://github.com/tibdex/shared-github-internals/blob/master/src/git.js#L22