search

fabric8io / fabric8-jenkinsfile-library

This repository contains a library of reusable Jenkinsfiles that you can use on your projects. Its reused by the fabric8 console to associate Jenkinsfiles to projects
Apache License 2.0
186 stars 67 forks source link

developer builds versus CD builds #10

Open jstrachan opened 7 years ago

jstrachan commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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