[feedhenry-dev] feedhenry-dev Digest, Vol 16, Issue 60

Thu Oct 26 08:18:43 UTC 2017

On Thu, Oct 26, 2017 at 9:56 AM, Craig Brookes <cbrookes at redhat.com> wrote:

> I think what you have outlined is great for our development releases,
> Matthias. If we haven't already we should update the doc.
>

Ok, cool -

I will weave that into the doc(s), and send PRs

>
> On the single repo, yes no git submodules, but I am big fan of it being in
> a single repo allow visibility for everything mcp that it happening and
> then syncing to separate repos for releases but as mentioned this is
> something we can get together and discuss as the f2f
>
> On Thu, Oct 26, 2017 at 8:52 AM, <feedhenry-dev-request at redhat.com> wrote:
>
>> Send feedhenry-dev mailing list submissions to
>>         feedhenry-dev at redhat.com
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://www.redhat.com/mailman/listinfo/feedhenry-dev
>> or, via email, send a message with subject or body 'help' to
>>         feedhenry-dev-request at redhat.com
>>
>> You can reach the person managing the list at
>>         feedhenry-dev-owner at redhat.com
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of feedhenry-dev digest..."
>>
>>
>> Today's Topics:
>>
>>    1. RFC: MCP-standalone Release Process (Matthias Wessendorf)
>>    2. Re: RFC: MCP-standalone Release Process (Phil Brookes)
>>    3. Re: RFC: MCP-standalone Release Process (Matthias Wessendorf)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Wed, 25 Oct 2017 20:20:30 +0200
>> From: Matthias Wessendorf <mwessend at redhat.com>
>> To: feedhenry-dev at redhat.com
>> Subject: [feedhenry-dev] RFC: MCP-standalone Release Process
>> Message-ID:
>>         <CAKUFdH1rt9y6Sirua0UxcsW6Ux+gO+xfP311=r5UAaJ5RPWcGg at mail.gm
>> ail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> 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-October/
>> msg00114.html
>>
>>
>> --
>> Project lead AeroGear.org
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <https://www.redhat.com/archives/feedhenry-dev/attachments/
>> 20171025/68d2a0d3/attachment.html>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 26 Oct 2017 08:43:13 +0100
>> From: Phil Brookes <pbrookes at redhat.com>
>> To: Matthias Wessendorf <mwessend at redhat.com>
>> Cc: feedhenry-dev at redhat.com
>> Subject: Re: [feedhenry-dev] RFC: MCP-standalone Release Process
>> Message-ID:
>>         <CAKY3PU2PvFvG_KwW5dDhGpEiZF8W+Frb1rUy0PUxPYt+t1QovA at mail.gm
>> ail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> 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_
>> > Process/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?
>> ? 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.
>>
>>
>> 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_
>> > Process/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_
>> > Process/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/
>> > 8d693cc6b2d58d9a2d83e33ea6cf9e31ce8bcac5
>> >
>> > 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/
>> > 260fd86868e7d12fb33197bf1ca9672a2f7d4b1a#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-
>> > October/msg00114.html
>> >
>> >
>> > --
>> > Project lead AeroGear.org
>> >
>> > _______________________________________________
>> > feedhenry-dev mailing list
>> > feedhenry-dev at redhat.com
>> > https://www.redhat.com/mailman/listinfo/feedhenry-dev
>> >
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <https://www.redhat.com/archives/feedhenry-dev/attachments/
>> 20171026/6dfa87dc/attachment.html>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Thu, 26 Oct 2017 09:52:05 +0200
>> From: Matthias Wessendorf <mwessend at redhat.com>
>> To: Phil Brookes <pbrookes at redhat.com>
>> Cc: feedhenry-dev at redhat.com
>> Subject: Re: [feedhenry-dev] RFC: MCP-standalone Release Process
>> Message-ID:
>>         <CAKUFdH3RTEHKW+ESRJcF7_9jz1LRvKMMwxPgFuXve+8tvbzHoA at mail.
>> gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> 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: <https://www.redhat.com/archives/feedhenry-dev/attachments/
>> 20171026/37a80476/attachment.html>
>>
>> ------------------------------
>>
>> _______________________________________________
>> feedhenry-dev mailing list
>> feedhenry-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>
>>
>> End of feedhenry-dev Digest, Vol 16, Issue 60
>> *********************************************
>>
>
>
>
> --
> Craig Brookes
> RHMAP
> @maleck13 Github
>
> _______________________________________________
> 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/13a8c700/attachment.htm>