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

Thu Oct 26 14:31:09 UTC 2017

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20171026/092b11b7/attachment.htm>