RFC: Release process for the Ansible Playbook Bundles (APBs)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: Release process for the Ansible Playbook Bundles (APBs)

Matthias Wessendorf
Hi,

we have some independent APBs, like for 3scale, Keycloak or AeroGear Digger, and those live in their own GH repository. We recently have converted their matching Dockerhub repositories to be build automatically once changes on the source code occur:

* master changes (e.g. PRs got merged) -> triggers a new build of the "latest" docker image
* Tags: pushing a new tag in github triggers a build of a "tagged" docker image. Current convention: GH tag == Docker tag (e.g. a version like "0.0.5" is same in both worlds)

How should we run releases for these APB repos ? 

Usually after changes did land on master, and there is a *demand* for a release, the last commit is used, and a tag is created and pushed to github. This also - as stated above - does release a matching Docker image to the wild. So far so good

For automation, we could use a little script like:

```bash
version="0.0.7-rc"                                                                              
latest_commit="$(git rev-parse HEAD)" | git tag -a ${version} ${latest_commit=} -m "signing tag" && git push origin ${version}
```

I personally would like to use -s, instead of -a, to actually sign the tag. This is a good practice that we are doing in AeroGear land (and other jboss projects). For more see [1].

Any thoughts?
-Matthias

PS: working on something similar for the MCP itself, which is a bit more tricky ;-)



--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Release process for the Ansible Playbook Bundles (APBs)

Wei Li
+1. What about change logs? can we auto-generate them as part of the release?

On Wed, Oct 25, 2017 at 9:18 AM, Matthias Wessendorf <[hidden email]> wrote:
Hi,

we have some independent APBs, like for 3scale, Keycloak or AeroGear Digger, and those live in their own GH repository. We recently have converted their matching Dockerhub repositories to be build automatically once changes on the source code occur:

* master changes (e.g. PRs got merged) -> triggers a new build of the "latest" docker image
* Tags: pushing a new tag in github triggers a build of a "tagged" docker image. Current convention: GH tag == Docker tag (e.g. a version like "0.0.5" is same in both worlds)

How should we run releases for these APB repos ? 

Usually after changes did land on master, and there is a *demand* for a release, the last commit is used, and a tag is created and pushed to github. This also - as stated above - does release a matching Docker image to the wild. So far so good

For automation, we could use a little script like:

```bash
version="0.0.7-rc"                                                                              
latest_commit="$(git rev-parse HEAD)" | git tag -a ${version} ${latest_commit=} -m "signing tag" && git push origin ${version}
```

I personally would like to use -s, instead of -a, to actually sign the tag. This is a good practice that we are doing in AeroGear land (and other jboss projects). For more see [1].

Any thoughts?
-Matthias

PS: working on something similar for the MCP itself, which is a bit more tricky ;-)



--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Release process for the Ansible Playbook Bundles (APBs)

Matthias Wessendorf
yep,

not done in a long time, but the AeroGear document says something like:

>>
...
git-extras installed, this way you can easily generate a change log by running git changelog , that will create an history.md file containing your changelog
...
>>

So, that could work and be evaluated ;-)



On Wed, Oct 25, 2017 at 10:41 AM, Wei Li <[hidden email]> wrote:
+1. What about change logs? can we auto-generate them as part of the release?

On Wed, Oct 25, 2017 at 9:18 AM, Matthias Wessendorf <[hidden email]> wrote:
Hi,

we have some independent APBs, like for 3scale, Keycloak or AeroGear Digger, and those live in their own GH repository. We recently have converted their matching Dockerhub repositories to be build automatically once changes on the source code occur:

* master changes (e.g. PRs got merged) -> triggers a new build of the "latest" docker image
* Tags: pushing a new tag in github triggers a build of a "tagged" docker image. Current convention: GH tag == Docker tag (e.g. a version like "0.0.5" is same in both worlds)

How should we run releases for these APB repos ? 

Usually after changes did land on master, and there is a *demand* for a release, the last commit is used, and a tag is created and pushed to github. This also - as stated above - does release a matching Docker image to the wild. So far so good

For automation, we could use a little script like:

```bash
version="0.0.7-rc"                                                                              
latest_commit="$(git rev-parse HEAD)" | git tag -a ${version} ${latest_commit=} -m "signing tag" && git push origin ${version}
```

I personally would like to use -s, instead of -a, to actually sign the tag. This is a good practice that we are doing in AeroGear land (and other jboss projects). For more see [1].

Any thoughts?
-Matthias

PS: working on something similar for the MCP itself, which is a bit more tricky ;-)



--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Release process for the Ansible Playbook Bundles (APBs)

Matthias Wessendorf
I just installed it: https://github.com/tj/git-extras/blob/master/Installation.md

and yep 'git changelog' generated the CHANGELOG.md file 

On Wed, Oct 25, 2017 at 10:45 AM, Matthias Wessendorf <[hidden email]> wrote:
yep,

not done in a long time, but the AeroGear document says something like:

>>
...
git-extras installed, this way you can easily generate a change log by running git changelog , that will create an history.md file containing your changelog
...
>>

So, that could work and be evaluated ;-)



On Wed, Oct 25, 2017 at 10:41 AM, Wei Li <[hidden email]> wrote:
+1. What about change logs? can we auto-generate them as part of the release?

On Wed, Oct 25, 2017 at 9:18 AM, Matthias Wessendorf <[hidden email]> wrote:
Hi,

we have some independent APBs, like for 3scale, Keycloak or AeroGear Digger, and those live in their own GH repository. We recently have converted their matching Dockerhub repositories to be build automatically once changes on the source code occur:

* master changes (e.g. PRs got merged) -> triggers a new build of the "latest" docker image
* Tags: pushing a new tag in github triggers a build of a "tagged" docker image. Current convention: GH tag == Docker tag (e.g. a version like "0.0.5" is same in both worlds)

How should we run releases for these APB repos ? 

Usually after changes did land on master, and there is a *demand* for a release, the last commit is used, and a tag is created and pushed to github. This also - as stated above - does release a matching Docker image to the wild. So far so good

For automation, we could use a little script like:

```bash
version="0.0.7-rc"                                                                              
latest_commit="$(git rev-parse HEAD)" | git tag -a ${version} ${latest_commit=} -m "signing tag" && git push origin ${version}
```

I personally would like to use -s, instead of -a, to actually sign the tag. This is a good practice that we are doing in AeroGear land (and other jboss projects). For more see [1].

Any thoughts?
-Matthias

PS: working on something similar for the MCP itself, which is a bit more tricky ;-)



--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    




--
Project lead AeroGear.org



--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Release process for the Ansible Playbook Bundles (APBs)

Matthias Wessendorf
In reply to this post by Matthias Wessendorf

For automation, we could use a little script like:

```bash
version="0.0.7-rc"                                                                              
latest_commit="$(git rev-parse HEAD)" | git tag -a ${version} ${latest_commit=} -m "signing tag" && git push origin ${version}
```
 

One more thought/comment. The "origin" does not ultimately fly - since folks could have renamed it to upstream etc. So, IMO that should be also a variable. 

More advanced tools, like the awesome maven-release-plugin, leverages that information from some SCM metadata in the pom.xml file:

But that's perhaps a bit of overhead here ;-)   So my initial vote would be make the name of the origin also configurable

Thoughts ?
-M



--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Release process for the Ansible Playbook Bundles (APBs)

Matthias Wessendorf
folks,

I've issued a first version of the release target:

 

On Wed, Oct 25, 2017 at 11:48 AM, Matthias Wessendorf <[hidden email]> wrote:

For automation, we could use a little script like:

```bash
version="0.0.7-rc"                                                                              
latest_commit="$(git rev-parse HEAD)" | git tag -a ${version} ${latest_commit=} -m "signing tag" && git push origin ${version}
```
 

One more thought/comment. The "origin" does not ultimately fly - since folks could have renamed it to upstream etc. So, IMO that should be also a variable. 

More advanced tools, like the awesome maven-release-plugin, leverages that information from some SCM metadata in the pom.xml file:

But that's perhaps a bit of overhead here ;-)   So my initial vote would be make the name of the origin also configurable

Thoughts ?
-M



--
Project lead AeroGear.org



--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev