Development branch and Travis CI

[lmcarboneau]

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 users

• We create a dev or WIP branch for all current development work; ALL PRs must be made against this branch so that it doesn't affect the stability of the main/master branch

• All 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 on dev/WIP and not the main/master branch; for example, if you are working on issue Implement logging #257 then you should create a new branch titled issue257 (or something similarly referenced) from the dev branch, complete and push work against the branch, and PR that branch against dev/WIP.

• Testing of the dev/WIP branch should be completed before merging with main/master.

• When we're ready to make an "official release" for a new version of PBjam, we PR the dev/WIP branch against main/master; when we merge the PR, we leave the dev branch open

Any 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

[grd349]

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 main through to dev/WIP and then again through to the issue257?

[lmcarboneau]

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:

[nielsenmb]

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> .

[lmcarboneau]

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:

• Create a dev branch
• Rebase outstanding branches/PRs on dev (or merge PRs and rebase dev on main after)
• Update contributing docs
  • Formalize the flowchart
• Do whatever needs doing to match main with distributors/PyPi
• Check that Travis is set up to only test on main and dev
  • and to ignore draft PRs (might do this by default)
• Figure out what's going on with GitHub workflows
• Figure out the Travis CI settings to ignore draft PRs

Anything missing?

[alexlyttle]

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 main will automatically create a release (will need to make sure we increment the version number)? I'm happy to help or look into this aspect.

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.

[lmcarboneau]

Suggestion - use GitHub workflows so that a merge to main will automatically create a release (will need to make sure we increment the version number)? I'm happy to help or look into this aspect.

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 don't think Travis ignores Draft PRs because mine was set as a Draft for ages and it was still trying to do tests.

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)

[lmcarboneau]

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)

Once these credits are used they are not replenished

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.

[alexlyttle]

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 pytest on their machines when making changes as a double-check. If users can't get pbjam working in their environment, they should also be encouraged to leave an issue.

[warrickball]

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 release branches), which I think is quite common. There's also a description on BitBucket that builds up more steadily to the full model. The diagrams in the links might help.

[lmcarboneau]

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!