Skip to content

Pushes to develop trigger all GHA workflows#995

Merged
nucleogenic merged 1 commit intodevelopfrom
nucleogenic-update-gha-triggers
Nov 18, 2022
Merged

Pushes to develop trigger all GHA workflows#995
nucleogenic merged 1 commit intodevelopfrom
nucleogenic-update-gha-triggers

Conversation

@nucleogenic
Copy link
Copy Markdown
Member

@nucleogenic nucleogenic commented Nov 18, 2022

Update to GHA triggers such that:

  • PR merges triggers all workflows
  • Direct pushes to develop triggers all workflows

Todo:

  • Test on forked repository

@sonarqubecloud
Copy link
Copy Markdown

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
No Duplication information No Duplication information

@nucleogenic
Copy link
Copy Markdown
Member Author

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 nucleogenic marked this pull request as ready for review November 18, 2022 16:05
@nucleogenic nucleogenic merged commit 8e6be98 into develop Nov 18, 2022
@rdmark rdmark deleted the nucleogenic-update-gha-triggers branch November 18, 2022 18:41
@uweseimet
Copy link
Copy Markdown
Contributor

uweseimet commented Nov 19, 2022

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

@nucleogenic
Copy link
Copy Markdown
Member Author

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.

@uweseimet
Copy link
Copy Markdown
Contributor

uweseimet commented Nov 19, 2022

@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.
Just like you I also don't like wasting build minutes, but I don't think GitHub provides any alternative.

@uweseimet
Copy link
Copy Markdown
Contributor

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

@nucleogenic
Copy link
Copy Markdown
Member Author

@uweseimet

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.

Please see PR #1003

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.

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.

@uweseimet
Copy link
Copy Markdown
Contributor

uweseimet commented Nov 21, 2022

@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.
This way as long as there is no PR only a single action would be triggered instead of two.

In case you agree and this can be configured you might consider updating the changes for #1003 before the merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants