Git Repository Monitor - Create build when a PR is created/updated

brandon_owensby_2976

I'm experimenting with the Git Repository Monitor and trying to replicate what we have with our current system. I have it creating builds but have a few questions on the settings as it isn't working as expected.

In my settings I set New Release Number to "pr-*" for starters but the release that was created was simply just "1". The "pr-" was totally ignored. On top of that I was curious if there was any variables that could be used in that field. I was specifically looking for a way to have the release number include the PR number. I looked through the documentation but was struggling to find specific stuff for that field.

atripp

Hi @brandon_owensby_2976 ,

Release Numbers in BuildMaster need to be numeric (e.g. 1, 1.2, or 1.2.3), so it's not possible to start a new release number with pr-*. The Release Name can be alphanumeric and does not need to be unique.

When you create a repository monitor, you can select "Only monitor branch when a pull request is open"; this will effectively allow you to create builds when a pull request is created, since the branch will be ignored until a PR exists.

However, the PR number is not automatically captured in the runtime state. In theory, you could query the GitHub API to find the PR by branch name if you really needed it.

Also note that you may find it easier and more reliable to trigger from the GitHub side of things, using the BuildMaster API. That's typically what we see for these more advanced scenarios.

Cheers,
Alana

brandon_owensby_2976

This post is deleted!

atripp

Hi @brandon_owensby_2976 ,

I'm not sure how easy it will be to replicate that UI and workflow of your current system. It sounds like you're doing some version of "Gitflow", where the "main" branch is "production-ready" and release-candidate builds are "chosen" from that.

BuildMaster uses a different workflow. As you may know, the BuildMaster model uses a Release as a logical set of Builds, with the intent that a single Build within a release will make it to production (final stage). Here's the article that explains is a bit more clearly:
https://docs.inedo.com/docs/buildmaster/modeling-your-applications/buildmaster-releases

Jenkins (and Gitflow) in general does not model Releases in this manner. Instead, it only has "builds", and a build is either a feature branch or a main. And the main build is what eventually gets deployed using a separate job, after a release engineer "picks the build they want" from a list of "main" builds.

The closest way to model this workflow in BuildMaster is to use release-less builds. In BuildMaster, the "Builds" listing will show the branch that is associated with the build, so you can easily see "main" and "branch" builds.

However, this is working a bit against the grain; Releases are a superior workflow model and solve a lot of business problems that Gitflow and "picking from a list of main builds" causes: https://blog.inedo.com/lean-platforms/releases

Here is some notes on our pattern for handling feature branches:
https://docs.inedo.com/docs/buildmaster/builds-continuous-integration/buildmaster-ci-git-workflows/buildmaster-git-feature-branches

Cheers,
Alana

brandon_owensby_2976

This post is deleted!

brandon_owensby_2976

Alana,

I totally understand everything you are saying and in the nearly 15 years I've being using BuildMaster this is the first time I've ever even considered anything like this. To be honest I don't like how our builds/releases are currently handled but being as new as I am with the company I don't have a lot of power there. I'm on this project to hopefully gain a little influence in this area though.

One thing I've learned in my time with this company, is there is at least some benefit to triggering a build for the PRs so you can require a successful build prior to allowing the PR to merge. I love the way Buildmaster handles things with releases, I just was hoping you had something to help separate the different types of release as you obviously support create a release off of a PR. Maybe that feature is something you added but not something Inedo fully believes in so you haven't spent a lot of time on the features around it (which would be totally understandable).

To be clear I'm not looking to 100% replicate the UI we currently use (I don't like most of it anyways). The only thing I'm interested in is keeping someone from losing the primary release in a bunch of PR releases. I had hoped that being able to add PR in front of the release name would help but it appears you guys support the number and not the name in that feature. If you have another idea up your sleeve I'd appreciate it, if not I understand.

Thank you,
Brandon

atripp

Hi @brandon_owensby_2976 ,

Thanks for the feedback, we appreciate it :)

There's definitely a value in building before merging; if you haven't already, I'd check out that feature branch article, as it outlines the pattern we use for it.

In general, the way I would try to configure is:

consider using a releaseless-build if you don't yet know the release it's targeting
use a different piepline so it's visually clear; the stages may be Build -> Test -> Merge
clean up the builds aftewards

That said, this isn't the most popular workflow in BuildMaster, so it may not be the most intuitive to implement or feel a bit clunky.

We don't have a lot of public examples, but the inedo-docs application is the closest to a Gitflow, releaseless type of workflow. Commits to master branch auto-deploy to live site, where as branches can only go to test:
https://buildmaster.inedo.com/applications/136/overview

No idea if that's helpful, but just FYI

Cheers,
Alana