RE: request for development/build workflow suggestion/fix

[<Graham.Menhennitt@c4i.com>]

Thanks for replying, Richard.

I'll have a think about your suggestion. It's a fairly radical change from what we currently do, but I'll consider it.

Thanks,
	Graham

-----Original Message-----
From: Kerry, Richard <richard.kerry@atos.net> 
Sent: Monday, 30 May 2022 7:32 PM
To: Graham.Menhennitt@c4i.com; git@vger.kernel.org
Subject: [EXTERNAL] RE: request for development/build workflow suggestion/fix

WARNING: Email originated from an EXTERNAL source. Do NOT click links, open attachments or reply unless you recognize sender and know the content is safe.

> -----Original Message-----
> From: Graham.Menhennitt@c4i.com <Graham.Menhennitt@c4i.com>
> Sent: 30 May 2022 02:45
> To: git@vger.kernel.org
> Subject: request for development/build workflow suggestion/fix
>

> Our (simplified) development workflow for fixing a bug or adding
> functionality:
> - clone the repo and create a private branch off the Integration 
> branch
> - fix the bug or develop the functionality (and test)
> - merge the private branch to Integration
> - create a tag to identify the fix
>
> Our build system:
> - clone the repo's Integration branch
> - edit a 'version' file in the repo that contains the current build 
> number and increment that number
> - build the software
> - commit the edited version file
> - create a tag identifying the build number
> - produce a list of changes since the previous build by diffing 
> between the newly created tag and the previous build tag
>
> The problem:
> - if a developer merges to Integration and creates a tag while the 
> build is in progress, his tag gets included in the diffs even though 
> his changes aren't actually included in the build.

> So, my question: can anybody please suggest an improvement to our 
> development or build workflows to fix/avoid the problem? The obvious 
> change of omitting the pulls before pushing from buildClone doesn't 
> work - git won't allow the push.
>
> Many thanks in advance for any suggestions.
>       Graham
>

Don't merge to the integration branch, commit to the development branch (ie the trunk) At the moment when a build is to be started, branch it generating a new integration branch (maybe also tag its start point).  Build from that.
Thus at that point in time it is frozen.  No-one commits to it.

Integration manager creates the integration branch and is then in control of what may be merged to it.  The rest of the team can commit to the development branch and their work will not hit integration without something being done explicitly to put it there.

Maybe,
Richard.