Pushes to develop trigger all GHA workflows#995
Conversation
|
Kudos, SonarCloud Quality Gate passed! |
|
Tested on my fork and seems to work as expected, so bringing this PR out of draft. https://github.com/nucleogenic/RASCSI/actions?query=branch%3Adevelop+event%3Apush |
|
@nucleogenic There is still something wrong: Changes in (new) branches do not trigger any action anymore. Without a PR nothing is built, no unit tests are run. |
|
Hi @uweseimet, this is by design, as we can raise a draft PR when we want feedback from CI. This prevents annoying and premature CI failure emails (and wasting build minutes, although they are free here). We can revert to the previous behaviour for the C++ workflows if you like? For Python it's actually much quicker to run the tools and get feedback locally. |
|
@nucleogenic I would very much appreciate having the previous behavior for C++ back. I need branches without PRs to test things and to see the SonarCloud results before I raise a PR. IMO forcing a PR for feedback from CI is a disadvantage, because everybody involved in this (draft) PR constantly gets e-mails with build messages. PRs should be raised when the respective funtionalitiy is available, because they deal with reviewing, not with sending the reviewer emails on intermediate commits. I have already been a victim of these emails, which is not nice. I avoid commenting on PRs now, because otherwise I get spam emails all the time. Previously this was not an issue, because commenting happened in the respective ticket, not in the PR. |
|
@nucleogenic One more thing: I noticed that recently there were PRs with a huge number of comments and changes. We never had such long-running PRs before. This is probably a result of your changes. But when you create PRs this early you get builds for each commit just as before, don't you? All in all this does not save any build minutes. But it increased the amount of spam emails sent. |
Please see PR #1003
I usually commit and push quite frequently due to working on two computers, but I will squash the commits if uninteresting to reviewers (e.g. anything like 'WIP - unit of work X') before the PR is raised, so it might not be obvious, but I would expect to see a reduction for my use case. Of course, it depends on the change set, how early feedback is needed from others, and how much change that feedback drives. Some changes like web UI theme and GHA changes are more opinionated, so attract a greater volume of feedback and changes. In any case, these things are not set in stone and I am happy to revert changes that don't work out. |
|
@nucleogenic At least from my perspective it would also be fine to just run the code analysis workflow on a push. Building everything is implicit for this workflow, i.e. the explicit build step does not provide much more insight than only running the analysis workflow. In case you agree and this can be configured you might consider updating the changes for #1003 before the merge. |








Update to GHA triggers such that:
Todo: