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

Thu Oct 26 14:31:27 UTC 2017

on the APBs, that's likely simpler :)

On Thu, Oct 26, 2017 at 4:31 PM, Matthias Wessendorf <mwessend at redhat.com>
wrote:

> ok,
>
> that's good info, I guess for MCP standalone developing this tool is a bit
> complex, but than I dont know enough about "package mgmt" w/ Go
>
>
>
>
>
>
> On Thu, Oct 26, 2017 at 4:18 PM, Leigh Griffin <lgriffin at redhat.com>
> wrote:
>
>> 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>
>>
>
>
>
> --
> Project lead AeroGear.org
>

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