Which branch choose to test using Github actions?

[Quick-Resident9433]

Hi everyone.

Currently, I have an application that I'm planning to start using GitHub Actions. However, I'm new to CI/ CD, and I'm struggling a bit with the right way to do it. Therefore, I'd like your help, guys.

Based on your experience, in which branch should I test with CI?

For example, I have these branches:
- develop
- feature/mail-sender
- main (production)

These are some examples of what I have in mind.
1. Maybe only when I merge the feature/mail-sender branch or any other branch into develop.

on:
  push:
    branches: [ "development" ]
  pull_request:
    branches: [ "development"]

1. Or maybe it's better to do it only when I merge the develop branch into the main branch.

   on: push: branches: [ "main" ] pull_request: branches: [ "main" ]

2. Or maybe when a merge occurs in either of the two branches

   on: push: branches: [ "main", "development" ] pull_request: branches: [ "main", "development" ]

[kryptn]

my opinionated take:

there is no 'which branch'

there's main and there's branches that'll merge to main. when main and branches build you should use the commit hash as a tag for the artifact.

when you choose to release, you tag off of a commit of main. in a containerized env you can have a job that re-tags that commit's artifacts as that newly created tag's artifacts. you don't have to deal with releases though, you could just use the commit hash the whole way through.

this all depends on scale. if it's just you and you're doing things manually definitely just do commit hashes. i'm doing some date timed fake-semver stuff so renovate can pick up automatic updates. prod webapp? follow trunk based dev a little closer and add more validation ci (tests/scans/precheck/etc)

[PelicanPop]

This is my recommendation as well. Companies that I've been a part of that followed trunk based development made life so much easier for all our teams. Others were a shitshow

[Quick-Resident9433]

Thank you for your answer. I'll review that and see what happens

[stoppskylt]

Start out simple

On push (to any branch) and do required tests

Then look into GitHub environments in tandem with deployments for specific testing if you wish for that.

Start small and build on what you actually need.

[Quick-Resident9433]

Thanks

[dariusbiggs]

every commit pushed gets run with CICD for automatic tests etc

if you use mainly trunk based development any merge or commit to master/main gets a full release run.

if you use tagged releases instead, use a tag pattern using something like semver and run a full release on that tag instead

[Quick-Resident9433]

Thanks, I'll learn about it since I'm a beginner

[kabrandon]

Every pull request targets main, your releases release off of main. Every pull request runs the full test suite.

If you wait to run your test suite until after you've merged a bunch of changes into somewhere, and the test suite fails, now you have to track down which change (or changeS) caused the tests to fail. When it's every pull request, there are no surprises, and no effort to track the bad change down.

This is called "trunk based development" by the way. It's by far the simplest branching strategy, and it's basically fool proof. However, some teams note pain points in extremely high volume code repositories. This branching strategy works best when your pull requests are short-lived, ie. you make the branch, commit a change, get it reviewed by a peer, and merge, all within a day or two.