[feedhenry-dev] RFC: MCP-standalone Release Process

Matthias Wessendorf mwessend at redhat.com
Thu Oct 26 07:52:05 UTC 2017


On Thu, Oct 26, 2017 at 9:43 AM, Phil Brookes <pbrookes at redhat.com> wrote:

> Hey Matthias,
>
> Now, the (three) dependent APBs of the MCP also need to be released. This
>> requires a bit of manual steps, as described here:
>> https://github.com/matzew/mcp-standalone/blob/Release_Proces
>> s/docs/Release.md#mcp-included-apbs
>>
>> 1) manual modify the openshift template (which is included in the
>> dependent APBs)
>> 2) creating image tags and pushing all to dockerhub (-> make apbs )
>>
>
> If the APBs that are currently included in the mcp-standalone repo were in
> their own separate repos (just like keycloak, 3scale, etc are currently)
> would that remove the requirement for these manual steps?
>

no - these three guys (android, ios, cordova) are special ABPs :-) They are
MCPs, and they need the updated template.
With a separated repo, they would each need a PR to get the updated version.



> ​ I think it would be superior if we could have a standard workflow that
> all APBs follow, rather than some APBs working one way and some working
> another and requiring developers to remember which is which.
>

So yeah, I think these three are a bit special :)

BTW. yesterday on IRC Craig suggested at our F2F in a couple of weeks we
all sit down and discuss a good approach for this. He mentione kubernetes,
where different things are in their own repos, but sync'd to the main one
(no damn gitsubmodules)



>
>
> Regards,
>
> Phil.​
>
>
>
>
> On Wed, Oct 25, 2017 at 7:20 PM, Matthias Wessendorf <mwessend at redhat.com>
> wrote:
>
>> Hi,
>>
>> as a follow up on [1], here are some thoughts on the MCP release itself.
>>
>> The raw process is described here:
>> https://github.com/matzew/mcp-standalone/blob/Release_Proces
>> s/docs/Release.md#mcp-release
>>
>> The first part is trivial (but not complete), we simply create a TAGGED
>> (versioned) image, and push it to docker. Afterwards the mcp-standalone in
>> dockerhub is updated.
>>
>> What's missing here is creation of a canonical TAG in git, more later;
>>
>> Now, the (three) dependent APBs of the MCP also need to be released. This
>> requires a bit of manual steps, as described here:
>> https://github.com/matzew/mcp-standalone/blob/Release_Proces
>> s/docs/Release.md#mcp-included-apbs
>>
>> 1) manual modify the openshift template (which is included in the
>> dependent APBs)
>> 2) creating image tags and pushing all to dockerhub (-> make apbs )
>>
>>
>> In 2) we also modify code, by copying the template over, for that I've
>> added a "release" commit in the Makefile target:
>> https://github.com/matzew/mcp-standalone/commit/8d693cc6b2d5
>> 8d9a2d83e33ea6cf9e31ce8bcac5
>>
>> But we still have a locally modified file on the disk (the original
>> openshift template). This is bad.
>> The changes to the template must be committed before we can actually move
>> on. To enforce that, I've added the following to the "make apbs" target:
>> https://github.com/feedhenry/mcp-standalone/commit/260fd8686
>> 8e7d12fb33197bf1ca9672a2f7d4b1a#commitcomment-25186889
>>
>> if there are not committed files, the "make apbs" fails- this is inspired
>> by the awesome ;-) Maven Release Plugin.
>>
>> As the last step, after the different pushes to dockerhub (mcp-standalone
>> and its dependent APBs), we must create a release tag in git, and push it.
>>
>> Only with these "rules" (e.g. no locally modified files, and proper
>> release tags, we end up having both in sync dockerhub images, and the
>> matching TAG in git)
>>
>> I think these new rules help to get a more solid release, and with a bit
>> of work can be applied by some "release script"
>>
>> But before hacking too much, I am generally interested in feedback on
>> these already committed changes.
>>
>> Thanks!
>> Matthias
>>
>>
>> [1] https://www.redhat.com/archives/feedhenry-dev/2017-Octob
>> er/msg00114.html
>>
>>
>> --
>> Project lead AeroGear.org
>>
>> _______________________________________________
>> feedhenry-dev mailing list
>> feedhenry-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>
>>
>


-- 
Project lead AeroGear.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20171026/37a80476/attachment.htm>


More information about the feedhenry-dev mailing list