developer builds versus CD builds

[jstrachan]

so we can easily use branch names to detect feature branches, issues, PRs and whatnot to kick in the CI / PR pipelines. We can treat 'master' as CD or developer builds pretty easily as an OOTB.

However given a repo in github org 'foo' where master is a CD build that generates a new versioned release on each merge.

Now if a user 'james' forks it; what should happen OOTB if there's a merge to the james repo? Feels like a good OOTB would be for it to be a developer build. i.e. the same branch name in a different namespace/organisation may want to disable the CD pipeline behaviour and use the developer pipeline instead.

Similarly if you just import any github repo which has our canonical CI / CD jenkinsfile into a different openshift cluster or namespace we maybe wanna default to 'developer build' (which does a mvn fabric8:deploy along with any CI tests).

i..e whether a branch in a git repo is a CD or developer build may not depend on whats in git; it may be an environmental configuration (something you configure in the namespace).

So I wonder if we should default to developer builds in our pipelines for master or feature branches; then CI builds for PRs / issues (using some well known naming convention).

Then when creating/importing a project a user can opt in to make master the 'CD release'. If they do that then we'd write a ConfigMap value somewhere that the master branch of that git repo was a CD release - if anyone else imports it it'd default to a developer branch?

[jstrachan]

one alternative to the ConfigMap would be to use the organisation + repo name + branch name to decide if its a CD build versus developer build; so that git lists the canonical organisation + repo + branch name that CD releases come from.

But that doesn't help the case where a 2 folks import the same project into 2 namespaces / clusters; you'd get 2 releases pipelines setup which isn't what folks typically would want

[rawlingsj]

Yeah I've been wondering about this too. As a developer that forks a repo we should probably automate the checking out of a feature or bug branch then that would avoid running a CD pipeline during development. Although that doesn't protect an accidental release in the users for if they push to master.

So having a check where the pipelines know the release org/repo/branch would be good.

[rawlingsj]

Then folks can use whatever workflow (gitflow etc) they choose