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

Thu Oct 26 14:18:15 UTC 2017

Just want to throw it out there that the XML Licenser is going to be a
requirement here. It's not a painful step in the above that you described
but it's a step nonetheless. So if our code is anything outside of Java
(maven based) or Node.js we might need to consider building a tool to
create the licensing information or reach out wider to find a team already
in flight on it.

On Thu, Oct 26, 2017 at 11:23 AM, David Martin <davmarti at redhat.com> wrote:

> Those release steps sound logical to me.
>
> It allows getting all apbs and the mcp version locked down so it can be
> tested and shared.
>
> As its mostly scripted already, it's setting us up nicely for automating
> the entire upstream release process.
>
> Having the various git repos tagged too is important to allow for
> downstream productisation, and  identifying when changes or bugs get
> introduced
>
>
>
> On 26 October 2017 at 08:52, Matthias Wessendorf <mwessend at redhat.com>
> wrote:
>
>>
>>
>> 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
>>
>> _______________________________________________
>> feedhenry-dev mailing list
>> feedhenry-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>
>>
>
>
> --
> David Martin
> Red Hat Mobile
> Twitter: @irldavem
> IRC: @irldavem (feedhenry, mobile-internal)
>
> _______________________________________________
> feedhenry-dev mailing list
> feedhenry-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>
>

-- 

LEIGH GRIFFIN

ENGINEERING MANAGER, MOBILE

Red Hat Ireland <https://www.redhat.com/>

Communications House, Cork Road

Waterford City, Ireland X91NY33

lgriffin at redhat.com    M: +353877545162     IM: lgriffin
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

@redhatway <https://twitter.com/redhatway>   @redhatinc
<https://instagram.com/redhatinc>   @redhatsnaps
<https://snapchat.com/add/redhatsnaps>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20171026/12f0a2f3/attachment.htm>