search

grd349 / PBjam

A repo for our peak baggin code and tips on jam
MIT License
17 stars 6 forks source link

Development branch and Travis CI #259

Closed lmcarboneau closed 1 month ago

lmcarboneau commented 3 years ago

To address some the issues with automated testing and integration with Travis CI, I want to propose a change to everyone:

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 notifications@github.com 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 https://github.com/grd349/PBjam/issues/259#issuecomment-784328554, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJWO3Y2FJHRBR3ILGSKV3DTAPJVHANCNFSM4YCX33OA .

lmcarboneau commented 3 years ago

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?

alexlyttle commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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!