-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Development branch and Travis CI #259
Comments
Yes - agreed to all of the above. Excellent thank @lmcarboneau ! That will put some other things on the todo list ... Update instructions for contributing - teach @grd349 how to do all of the above - others I'm sure. Is it the still easy to pull |
It should be yeah, it would be something like using the command This would come up if someone else's PR is merged before yours, so you might be in the Hopefully that answers the question. If it helps, here's a really messy sketch of the flowchart: |
Can we include the sketch as reference material to explain contributing
code? It's excellent.
I like this idea. It'll make it easier to match main with the PyPi version.
…On Tue, 23 Feb 2021 at 16:29, Lindsey Carboneau ***@***.***> wrote:
Is it the still easy to pull main through to dev/WIP and then again
through to the issue257?
It should be yeah, it would be something like using the command git
rebase main from whichever branch you're on.
This would come up if someone else's PR is merged before yours, so you
might be in the issue257 branch and need to run git rebase dev before
merging; once the dev branch is merged into main for a release they'll be
up-to-date with each other, but in a pinch instead of rewinding commits you
can always run git rebase main from dev to undo major/breaking changes.
Hopefully that answers the question. If it helps, here's a really messy
sketch of the flowchart:
<https://user-images.githubusercontent.com/4117599/108874358-ff8f0d80-75f3-11eb-9dfd-0a03a512a1fb.png>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#259 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEJWO3Y2FJHRBR3ILGSKV3DTAPJVHANCNFSM4YCX33OA>
.
|
We definitely can, I can make a more... typeset version of it too 😂 Alrighty! I'm happy to volunteer to update the contributing section as well, while I'm at it. Might be a day or two but I'll start in on it. I think the To Do list goes something like:
Anything missing? |
This all sounds good to me! Great plan @lmcarboneau 😁 If there is anything I need to do with my current PR #257 then let me know too? Suggestion - use GitHub workflows so that a merge to I don't think Travis ignores Draft PRs because mine was set as a Draft for ages and it was still trying to do tests. |
Oooh, I like that idea, that's nice. We can make an automated release note/docs update to go with it, but maybe that's taking things a bit too far haha
I'll look into finding the settings, see if there's a way to turn it on. It should be capable of it at least, but maybe not by default. It's added to the list 😄 Sorry to be hounding your PR too, I didn't want to use #258 since I wasn't sure what was up with it and it seems like maybe #257 is in a good place to merge (barring the blocking checks thing) |
Turns out Draft PRs used to be disabled by default for builds but a bunch of people complained so now they auto build 🙄 I don't know why there isn't a toggle switch for it. I'm not certain I know where the setting is, but there are some things to try (which will involve editing the .yaml because there's no easy toggle on the dashboard)
This is what happened to Travis, we went through our 10k credits and so we're out now. We can request more, but it's not an automated thing. I'm on it! We might also consider limiting the environments we build on - Guy mentioned removing the Mac tests and I'm happy to do that, but we can consider bringing our 3 Linux builds down too. |
We could just have one linux environment with the latest version of Python (currently 3.9) and another with the earliest which we are compatible with (3.6)? We could also encourage contributors to run |
Just chipping in from the sidelines that @lmcarboneau's suggestion is a slight variant of what is now often called the "Gitflow" workflow (but perhaps without the |
That's really great, thank you @warrickball! I hadn't heard the term used before, and it didn't occur to me to go looking. I especially like that BitBucket link, I'm going to review that more closely. The suggestion was based off my fading memory of project teams in the past, so it's nice to see it all laid out and with the commands! |
To address some the issues with automated testing and integration with Travis CI, I want to propose a change to everyone:
The
main/master
branch is the current release branch; it is the public code that we recommend to usersWe create a
dev
orWIP
branch for all current development work; ALL PRs must be made against this branch so that it doesn't affect the stability of themain/master
branchAll PRs should be opened in Draft mode first, especially if you're looking for comments and review; PRs should only be promoted out of Draft mode when the author is fully ready to merge (and preferably has submitted their own local pytest results).
When opening a PR against the
dev/WIP
branch, it should be made from a feature branch based ondev/WIP
and not themain/master
branch; for example, if you are working on issue Implement logging #257 then you should create a new branch titledissue257
(or something similarly referenced) from thedev
branch, complete and push work against the branch, and PR that branch againstdev/WIP
.Testing of the
dev/WIP
branch should be completed before merging withmain/master
.When we're ready to make an "official release" for a new version of PBjam, we PR the
dev/WIP
branch againstmain/master
; when we merge the PR, we leave thedev
branch openAny thoughts? Questions? Hopefully this doesn't represent a huge change to anyone's workflows, and is easy to keep track of. Speaking of workflows, it looks like it's still running against some of the PRs, so finding a way to fully remove it should be on the to-do list (it looks like it's blocking one of Alex's PRs at the moment?)
I'm especially looking for feedback from @grd349 , @nielsenmb and @alexlyttle
The text was updated successfully, but these errors were encountered: