Ci/circleci test and pull request reviews?

Is the ci/circleci test done on pull requests a new one? I submitted a PR 12 days ago:
https://github.com/home-assistant/home-assistant/pull/22411
It initially passed all tests, but now I’m seeing its waiting for a range of ci/circleci tests
How long does that normally take?
Also, I see somebody else made a small change to one of the files 4 days ago. He was a little more succesful at getting a review :slight_smile:
What do I do from now? start over or just make another commit where I include his changes?

Also, how likely is it that I will see a review? After 0.91 I can no longer use my changes locally asa custom_component unless I rename the component completely. This would change a lot of other stuff in my code, so I am of course more interested in getting the changes implemented.

You can rebase on up to date dev branch or merge the up to date dev branch into your branch to get the updates. This should start the new tests automatically.

For reviews, it seems to be a waiting game and it is variable. I’ve done 2 PRs, one was merged into the frontend and added to the frontend release within an hour of submission. The other sat for more than a month before I politely asked a few times on the discord chat for a review.

1 Like

Thanks,

I do have a question about posting pull requests. I tried to push directly from local Dev to home-assistant/ home-assistant but it said I didn’t have permission to do that. Should I be able to? Instead I had to push to a fork and then create my pull request from there. Is that the required way to do it?

There are usually three repos at play. 1) homeassistant/homeassistant on GitHub, 2) user/homeassistant on GitHub (forked from 1), 3) local homeassistant repo (cloned from 2).

You don’t have write permissions on any branch of 1. So you have to create a branch on your forked version, which you do have write permissions. Then sometimes you need to grab changes from repo 1, so it is common to add repo 1 as a remote repo, usually as upstream. Then you can pull changes from upstream.

There are a lot of guides out there, here’s one:
https://akrabat.com/the-beginners-guide-to-contributing-to-a-github-project/

Thanks,

Yes, thats the way I ended up doing it. I do have an additional question.

My initial Commit was a bugfix and I did have a couple of people review it and say ok for it. Still no assignee.
I then committed some improvements to functionality thinking I would be able to create a new Pull request, but these commits ended up in the same Pull Request.

  1. How should I have proceeded to create a new Pull Request before the old one was merged?
  2. What will happen with my current pull request now that it has one commit thats reviewed and some that are not? Can they merge the approved commit or does it all have to be done in one process, so all commits have to be reviewed before merge?

Here is the Pull request in question:

You need to create a new branch. The usual method is to branch off of dev for a completely separate fix that is not dependant on your previous PR.

You probably did the right thing reverting back to the approved changes. If your new fix is dependent on the old one, you can either wait until it is merged into dev. Then update your repo with the upstream repo and then check out a new branch from the up to date dev branch. Or, I think you can branch off of your current fix branch, but this is starting to get into unfamiliar territory for me.

If I were a reviewer, I would probably take a second look at the changes just to double check it was in the approved state.

PS the best thing to do is to keep all of your actions transparent, which you’ve been doing it seems. Most devs will be happy to help someone along the process as long as you make it easy for them

Thanks. It’s merged now, so I have created a new request:

Thank you for your help. I think I’m starting to slowly understand the process now :slight_smile: