Are we crushing travis CI?

[sliptonic]

There's now 48 open PRs and travis seems to be out to lunch.

I've noticed more and more people creating 'Draft' PRs and then working on them for a while. Since every push to the repo linked by the PR restarts the build process, it seems like maybe this isn't such a good idea.

Is there anything else we can do to pause the building on specific PRs until the DRAFT tag is removed? If not maybe we need some guidance on when to actually create a PR.

[saso]

I have said it a long time ago that people should stop developing directly on the master and in the master PR...

[carlopav]

I guess I'm (one of the) the culprit
Draft PRs are really useful to me because others can correct my code on the fly (my contributions are in my separate branches, but with Draft PR other users are up to date with ongoing development). I'm actually learning a lot through this process.
IMHO it sounds good if we can disable compiling for draft PRs, if it's not possible, I can change the way I'm doing it.

[wandererfan]

There's now 48 open PRs and travis seems to be out to lunch.

I've noticed more and more people creating 'Draft' PRs and then working on them for a while. Since every push to the repo linked by the PR restarts the build process, it seems like maybe this isn't such a good idea.

Travis status report says they had a problem with jobs queuing, but not executing. Problem reported fixed today at 1400 UTC, but I don't see any motion in our backlog yet (1648 UTC).

There are a number of Draft WB PRs in the queue (awaiting merge?), but from a quick look, there have been no recent pushes for them.

[wandererfan]

So these are Draft Draft PRs?

[sliptonic]

I guess I'm (one of the) the culprit
Draft PRs are really useful to me because others can correct my code on the fly (my contributions are in my separate branches, but with Draft PR other users are up to date with ongoing development). I'm actually learning a lot through this process.
IMHO it sounds good if we can disable compiling for draft PRs, if it's not possible, I can change the way I'm doing it.

I'm also a culprit. Didn't mean that to sound like a criticism. I just don't know what 'best practice _should_ be.

[carlopav]

So these are Draft Draft PRs?

There are a looot of Draft Workbench PRs, but some of them are Draft Workbench Draft PRs.
Edit: i just red one Draft in your sentence before! Draft Draft PRs, exactly!

[carlopav]

I'm also a culprit. Didn't mean that to sound like a criticism. I just don't know what 'best practice _should_ be.

Don't worry, I was ironic. And I of course accept any advice that can improve the overall dev experience.

[vocx]

...
Is there anything else we can do to pause the building on specific PRs until the DRAFT tag is removed? If not maybe we need some guidance on when to actually create a PR.

Just to support what wandererfan says, I also think this is something on Travis's side. Maybe some of you didn't notice but there was a day when Travis was completely unavailable; trying to access it showed a "currently in maintenance" page. I remember at that time Kunda was also complaining about the GitHub-Mantis tracker bug report association not working.

My theory is just that the services (GitHub, Travis, etc.) were unavailable due to increased global demand, people working from home and so on. I don't think it's a problem of FreeCAD in particular. I think we should just wait.

---

As for the frequency of Draft pull requests. I don't think we need hard rules on that.

Draft pull request were implemented in GitHub very recently, beginning of 2019. I had never used them before because I didn't know about them, until I saw one, and now I like using them. It's just a way to mark your pull request as work in progress. I don't think there is anything bad about it. The old way, which is what many people still do currently, is simply to assign a title to the pull request like "HOLD", "DO NOT MERGE", "Work in Progress", etc. It's just a way to stop administrators from merging work in progress code.

Submitting Draft pull requests is not bad in my opinion, because you can precisely run the unit tests online and catch errors before they are integrated into the master branch. Sometimes these errors occur in the Travis system and not in your own system. However, programmers should have a bit of patience and not commit very often to try this out.

In particular, I've noticed that if the pull request contains a Travis error, it will take a long time of compilation time, up to 6 hours. My guess is these pull requests don't use the cache, making the following commits also very slow. On the other hand, commits that pass all tests are pretty fast, like it uses the cache correctly.

So, my general recommendation is always to test your code locally (unit tests) before submitting the code online. I don't know how many people do that, but if you do, you help everybody get their pull requests tested more quickly. I always test my code locally before submitting changes to a pull request.

And also, who are the administrators? You can cancel the build of pull requests if they are taking too long. Check this regularly. Don't cancel everybody else's pull requests, but if you want to check something, do it.

[vocx]

I have said it a long time ago that people should stop developing directly on the master and in the master PR...

This doesn't make sense. Nobody develops on the master branch. Only Werner consistently modifies the master branch, and sometimes Yorik.

The rest of us submit pull requests, so we develop in our own branches, and then submit pull requests.