Date   
Publishing docs

Jeremy Phelps
 

Hi Steve and Andy,
I want to go ahead and get a start on building out a jenkins job that generates the html.  A good start will be just to get ahold of your script that do that....which I can then insert/translate into JJB.

Once that is done I'll set up a site repo to host the docs at nexus.edgexfoundry.org

Thanks,
Jeremy

EdgeX Core Working Group meeting tomorrow at 10am CDT

James.White2@...
 

All, reminder that our Core Working Group meeting will be held tomorrow at 10am CDT.  Find the agenda and connection information here:  https://wiki.edgexfoundry.org/display/FA/Core+Working+Group

Agenda items for tomorrow include: opening working group chair nominations (for those working groups that meet during this time), Palo Alto Face 2 Face planning, DS requirements discussion and much more.

 

Jim White

Distinguished Engineer, IoT Platform Development Team Lead

Dell Technologies | IoT Solutions Division

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

 

Build Failure notification on blackbox-tests

Jeremy Phelps
 

Hi All,
If you would like to be notified by email when there is a blackbox-testing run that fails go to
Jeremy

Re: [Edgex-devel] Publishing of edgex-go binaries and docker images

Jeremy Phelps
 

Also it looks like we will need to ship the launch script and config files with the go binaries.

On Fri, May 11, 2018 at 2:08 PM, Jeremy Phelps <jphelps@...> wrote:
Note that we may run into some issues on Caviums static build machine.  I think there may be some issues there since the docker images on the machine are available across all builds.

On Fri, May 11, 2018 at 2:02 PM, Jeremy Phelps <jphelps@...> wrote:
Hi Folks,
The docker images and go binaries for edgex-go are now being regularly pushed to nexus.

The images build during a PR merge are published at:
        https://nexus3.edgexfoundry.org/#browse/browse:docker.snapshot

The images built on a daily cron (tip of master) are published at:
        https://nexus3.edgexfoundry.org/#browse/browse:docker.staging

The go binaries are in a tar.gz file.

The bins built during a PR merge are in the snapshots folder and the daily builds are in the staging folder here:
        https://nexus.edgexfoundry.org/content/sites/edgex-go/


Reach out to me if you see anything odd or if you have suggestions on different tagging/naming schemes.

To unpack the binaries just download the respective tar.gz and do:

tar -xzf <file.tar.gz>

Jeremy



Re: [Edgex-devel] Publishing of edgex-go binaries and docker images

Jeremy Phelps
 

Note that we may run into some issues on Caviums static build machine.  I think there may be some issues there since the docker images on the machine are available across all builds.

On Fri, May 11, 2018 at 2:02 PM, Jeremy Phelps <jphelps@...> wrote:
Hi Folks,
The docker images and go binaries for edgex-go are now being regularly pushed to nexus.

The images build during a PR merge are published at:
        https://nexus3.edgexfoundry.org/#browse/browse:docker.snapshot

The images built on a daily cron (tip of master) are published at:
        https://nexus3.edgexfoundry.org/#browse/browse:docker.staging

The go binaries are in a tar.gz file.

The bins built during a PR merge are in the snapshots folder and the daily builds are in the staging folder here:
        https://nexus.edgexfoundry.org/content/sites/edgex-go/


Reach out to me if you see anything odd or if you have suggestions on different tagging/naming schemes.

To unpack the binaries just download the respective tar.gz and do:

tar -xzf <file.tar.gz>

Jeremy


Publishing of edgex-go binaries and docker images

Jeremy Phelps
 

Hi Folks,
The docker images and go binaries for edgex-go are now being regularly pushed to nexus.

The images build during a PR merge are published at:
        https://nexus3.edgexfoundry.org/#browse/browse:docker.snapshot

The images built on a daily cron (tip of master) are published at:
        https://nexus3.edgexfoundry.org/#browse/browse:docker.staging

The go binaries are in a tar.gz file.

The bins built during a PR merge are in the snapshots folder and the daily builds are in the staging folder here:
        https://nexus.edgexfoundry.org/content/sites/edgex-go/


Reach out to me if you see anything odd or if you have suggestions on different tagging/naming schemes.

To unpack the binaries just download the respective tar.gz and do:

tar -xzf <file.tar.gz>

Jeremy

Re: Docker squash option

James.White2@...
 

Dell - Internal Use - Confidential

+1

 

From: Jeremy Phelps [mailto:jphelps@...]
Sent: Thursday, May 10, 2018 7:21 PM
To: White2, James
Cc: edgex-tsc-devops@...
Subject: Re: [Edgex-tsc-devops] Docker squash option

 

Hey Jim,

The only downside I think is that it could go away since it is experimental, I'll do some reading and see if I can find out a roadmap for the feature.

That said, it is possible to squash your own image out side of the "docker" tool chain.  I'd say this will be a Dehli item to look at.

Jeremy

 

On Thu, May 10, 2018 at 7:13 PM, <James.White2@...> wrote:

Dell - Internal Use - Confidential

Hi Jeremy,

I like the premise and the sample numbers.  Do you see any potential downsides or issues?  We should try it out.

j

 

From: EdgeX-TSC-DevOps@... [mailto:EdgeX-TSC-DevOps@...] On Behalf Of Jeremy Phelps
Sent: Thursday, May 10, 2018 6:29 PM
To: edgex-tsc-devops@...
Subject: [Edgex-tsc-devops] Docker squash option

 

docker --squash is an experimental feature but I wanted to get some thoughts on EdgeX trying it out.
http://jasonwilder.com/blog/2014/08/19/squashing-docker-images/

Another possibility to decrease the footprint.

Jeremy

 

Re: Docker squash option

Jeremy Phelps
 

Hey Jim,
The only downside I think is that it could go away since it is experimental, I'll do some reading and see if I can find out a roadmap for the feature.
That said, it is possible to squash your own image out side of the "docker" tool chain.  I'd say this will be a Dehli item to look at.
Jeremy

On Thu, May 10, 2018 at 7:13 PM, <James.White2@...> wrote:

Dell - Internal Use - Confidential

Hi Jeremy,

I like the premise and the sample numbers.  Do you see any potential downsides or issues?  We should try it out.

j

 

From: EdgeX-TSC-DevOps@lists.edgexfoundry.org [mailto:EdgeX-TSC-DevOps@lists.edgexfoundry.org] On Behalf Of Jeremy Phelps
Sent: Thursday, May 10, 2018 6:29 PM
To: edgex-tsc-devops@lists.edgexfoundry.org
Subject: [Edgex-tsc-devops] Docker squash option

 

docker --squash is an experimental feature but I wanted to get some thoughts on EdgeX trying it out.
http://jasonwilder.com/blog/2014/08/19/squashing-docker-images/

Another possibility to decrease the footprint.

Jeremy


Re: Docker squash option

James.White2@...
 

Dell - Internal Use - Confidential

Hi Jeremy,

I like the premise and the sample numbers.  Do you see any potential downsides or issues?  We should try it out.

j

 

From: EdgeX-TSC-DevOps@... [mailto:EdgeX-TSC-DevOps@...] On Behalf Of Jeremy Phelps
Sent: Thursday, May 10, 2018 6:29 PM
To: edgex-tsc-devops@...
Subject: [Edgex-tsc-devops] Docker squash option

 

docker --squash is an experimental feature but I wanted to get some thoughts on EdgeX trying it out.
http://jasonwilder.com/blog/2014/08/19/squashing-docker-images/

Another possibility to decrease the footprint.

Jeremy

Docker squash option

Jeremy Phelps
 

docker --squash is an experimental feature but I wanted to get some thoughts on EdgeX trying it out.
http://jasonwilder.com/blog/2014/08/19/squashing-docker-images/
Another possibility to decrease the footprint.
Jeremy

Re: [Jenkins] Build plugin for github repositories

James.White2@...
 

Dell - Internal Use - Confidential

Perfect

 

From: Андрій Попович [mailto:popovych.andrey@...]
Sent: Wednesday, May 09, 2018 4:50 PM
To: White2, James
Cc: EdgeX-TSC-DevOps@...
Subject: Re: [Edgex-tsc-devops] [Jenkins] Build plugin for github repositories

 

Hi Jim,

 

Probably I'll create an issue on github.

 

Thanks,

Andriy

 

ср, 9 трав. 2018, 23:17 користувач <James.White2@...> пише:

Dell - Internal Use - Confidential 

Hi Andriy,
Jeremy Phelps (DevOps chair) and I had an exchange on this.  Jeremy agrees that it would provide benefits regarding the latest build info to folks only browsing the GitHub repo.  Unfortunately, at the moment, all hands are working toward higher priority items for the upcoming California release.  After that release is out, Jeremy is going to take a look at try to implement this in our Jenkins instance.  I might ask that you use this same email reflector to post a reminder after June 29th.
Thanks for the proposal Andriy,
Jim

-----Original Message-----
From: EdgeX-TSC-DevOps@... [mailto:EdgeX-TSC-DevOps@...] On Behalf Of ?????? ???????
Sent: Thursday, May 03, 2018 12:01 PM
To: EdgeX-TSC-DevOps@...
Subject: [Edgex-tsc-devops] [Jenkins] Build plugin for github repositories

Hi folks,

I'd like to propose jenkins plugin:
https://plugins.jenkins.io/embeddable-build-status

This one can embed build status in github project repose.
It can be useful for quick look whats going on with master.

Regards,
Andriy




Re: [Jenkins] Build plugin for github repositories

Андрій Попович <popovych.andrey@...>
 

Hi Jim,

Probably I'll create an issue on github.

Thanks,
Andriy

ср, 9 трав. 2018, 23:17 користувач <James.White2@...> пише:

Dell - Internal Use - Confidential 

Hi Andriy,
Jeremy Phelps (DevOps chair) and I had an exchange on this.  Jeremy agrees that it would provide benefits regarding the latest build info to folks only browsing the GitHub repo.  Unfortunately, at the moment, all hands are working toward higher priority items for the upcoming California release.  After that release is out, Jeremy is going to take a look at try to implement this in our Jenkins instance.  I might ask that you use this same email reflector to post a reminder after June 29th.
Thanks for the proposal Andriy,
Jim

-----Original Message-----
From: EdgeX-TSC-DevOps@... [mailto:EdgeX-TSC-DevOps@...] On Behalf Of ?????? ???????
Sent: Thursday, May 03, 2018 12:01 PM
To: EdgeX-TSC-DevOps@...
Subject: [Edgex-tsc-devops] [Jenkins] Build plugin for github repositories

Hi folks,

I'd like to propose jenkins plugin:
https://plugins.jenkins.io/embeddable-build-status

This one can embed build status in github project repose.
It can be useful for quick look whats going on with master.

Regards,
Andriy






Re: [Jenkins] Build plugin for github repositories

James.White2@...
 

Dell - Internal Use - Confidential

Hi Andriy,
Jeremy Phelps (DevOps chair) and I had an exchange on this. Jeremy agrees that it would provide benefits regarding the latest build info to folks only browsing the GitHub repo. Unfortunately, at the moment, all hands are working toward higher priority items for the upcoming California release. After that release is out, Jeremy is going to take a look at try to implement this in our Jenkins instance. I might ask that you use this same email reflector to post a reminder after June 29th.
Thanks for the proposal Andriy,
Jim

-----Original Message-----
From: EdgeX-TSC-DevOps@... [mailto:EdgeX-TSC-DevOps@...] On Behalf Of ?????? ???????
Sent: Thursday, May 03, 2018 12:01 PM
To: EdgeX-TSC-DevOps@...
Subject: [Edgex-tsc-devops] [Jenkins] Build plugin for github repositories

Hi folks,

I'd like to propose jenkins plugin:
https://plugins.jenkins.io/embeddable-build-status

This one can embed build status in github project repose.
It can be useful for quick look whats going on with master.

Regards,
Andriy

Re: Docker publish conventions

Jeremy Phelps
 

Absolutely, sounds like a plan

On Thu, May 3, 2018 at 3:25 PM, <James.White2@...> wrote:

Dell - Internal Use - Confidential

Jeremy – do you want to do some prototyping first and see if this works well… and if so cover in next week’s core working group to get input / feedback?

Jim

 

From: EdgeX-TSC-DevOps@lists.edgexfoundry.org [mailto:EdgeX-TSC-DevOps@lists.edgexfoundry.org] On Behalf Of Jeremy Phelps
Sent: Thursday, May 03, 2018 1:45 PM
To: Conn, Trevor
Cc: EdgeX-TSC-DevOps@lists.edgexfoundry.org
Subject: Re: [Edgex-tsc-devops] Docker publish conventions

 

Just thought of a way, we could template out a docker-compose file for each staging push that blackbox tests would pull in.  We could interpolate the SHA tags into it.  Will take a bit of figuring though.

 

On Thu, May 3, 2018 at 1:41 PM, Jeremy Phelps <jphelps@...> wrote:

I just thought of a blocker on SHA tag in staging for blackbox tests, not sure there would be a way to automate pulling those in.

 

On Thu, May 3, 2018 at 1:38 PM, <Trevor.Conn@...> wrote:

Works for me, and I agree "staging" should also have the SHA tag.

 

Trevor Conn
Senior Principal Software Engineer
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA


From: EdgeX-TSC-DevOps@lists.edgexfoundry.org <EdgeX-TSC-DevOps@lists.edgexfoundry.org> on behalf of Jeremy Phelps <jphelps@...>
Sent: Thursday, May 3, 2018 1:32 PM
To: edgex-tsc-devops@lists.edgexfoundry.org
Subject: [Edgex-tsc-devops] Docker publish conventions

 

Hi All,

I wanted to get some feed back on my following proposal for publishing docker images to the edgexfoundry docker registries:
"""

# DEPLOY_TYPE: Can be `snapshot`, `staging` or`release`

# `snapshot` will push docker images to:

# 1) nexus3.edgexfoundry.org:10003 with a GIT_SHA-VERSION tag

# `staging` will push docker images to:

# 1) nexus3.edgexfoundry.org:10004 with the `latest` tag

# 2) edgexfoundry dockerhub with the `latest` tag

# `release` will push docker images to:

# 1) nexus3.edgexfoundry.org:10002 with the `latest` tag and `VERSION` tag

# 2) edgexfoundry dockerhub with the `latest` tag and `VERSION` tag

#


"""

VERSION is set by reading the VERSION file in the project root.

 

We could then direct the blackbox tests against the staging repository 'latest' daily.  It might be helpful to interpolate the GIT_SHA into the tag for the staging repo images so we can trace back easier in the event of failure.

Thoughts?

Jeremy

 

 


Re: Docker publish conventions

James.White2@...
 

Dell - Internal Use - Confidential

Jeremy – do you want to do some prototyping first and see if this works well… and if so cover in next week’s core working group to get input / feedback?

Jim

 

From: EdgeX-TSC-DevOps@... [mailto:EdgeX-TSC-DevOps@...] On Behalf Of Jeremy Phelps
Sent: Thursday, May 03, 2018 1:45 PM
To: Conn, Trevor
Cc: EdgeX-TSC-DevOps@...
Subject: Re: [Edgex-tsc-devops] Docker publish conventions

 

Just thought of a way, we could template out a docker-compose file for each staging push that blackbox tests would pull in.  We could interpolate the SHA tags into it.  Will take a bit of figuring though.

 

On Thu, May 3, 2018 at 1:41 PM, Jeremy Phelps <jphelps@...> wrote:

I just thought of a blocker on SHA tag in staging for blackbox tests, not sure there would be a way to automate pulling those in.

 

On Thu, May 3, 2018 at 1:38 PM, <Trevor.Conn@...> wrote:

Works for me, and I agree "staging" should also have the SHA tag.

 

Trevor Conn
Senior Principal Software Engineer
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA


From: EdgeX-TSC-DevOps@... <EdgeX-TSC-DevOps@...> on behalf of Jeremy Phelps <jphelps@...>
Sent: Thursday, May 3, 2018 1:32 PM
To: edgex-tsc-devops@...
Subject: [Edgex-tsc-devops] Docker publish conventions

 

Hi All,

I wanted to get some feed back on my following proposal for publishing docker images to the edgexfoundry docker registries:
"""

# DEPLOY_TYPE: Can be `snapshot`, `staging` or`release`

# `snapshot` will push docker images to:

# 1) nexus3.edgexfoundry.org:10003 with a GIT_SHA-VERSION tag

# `staging` will push docker images to:

# 1) nexus3.edgexfoundry.org:10004 with the `latest` tag

# 2) edgexfoundry dockerhub with the `latest` tag

# `release` will push docker images to:

# 1) nexus3.edgexfoundry.org:10002 with the `latest` tag and `VERSION` tag

# 2) edgexfoundry dockerhub with the `latest` tag and `VERSION` tag

#


"""

VERSION is set by reading the VERSION file in the project root.

 

We could then direct the blackbox tests against the staging repository 'latest' daily.  It might be helpful to interpolate the GIT_SHA into the tag for the staging repo images so we can trace back easier in the event of failure.

Thoughts?

Jeremy

 

 

Re: Docker publish conventions

Jeremy Phelps
 

Just thought of a way, we could template out a docker-compose file for each staging push that blackbox tests would pull in.  We could interpolate the SHA tags into it.  Will take a bit of figuring though.

On Thu, May 3, 2018 at 1:41 PM, Jeremy Phelps <jphelps@...> wrote:
I just thought of a blocker on SHA tag in staging for blackbox tests, not sure there would be a way to automate pulling those in.

On Thu, May 3, 2018 at 1:38 PM, <Trevor.Conn@...> wrote:

Works for me, and I agree "staging" should also have the SHA tag.


Trevor Conn
Senior Principal Software Engineer
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA

From: EdgeX-TSC-DevOps@...undry.org <EdgeX-TSC-DevOps@...oundry.org> on behalf of Jeremy Phelps <jphelps@...>
Sent: Thursday, May 3, 2018 1:32 PM
To: edgex-tsc-devops@...undry.org
Subject: [Edgex-tsc-devops] Docker publish conventions
 
Hi All,
I wanted to get some feed back on my following proposal for publishing docker images to the edgexfoundry docker registries:
"""
# DEPLOY_TYPE: Can be `snapshot`, `staging` or`release`
# `snapshot` will push docker images to:
# 1) nexus3.edgexfoundry.org:10003 with a GIT_SHA-VERSION tag
# `staging` will push docker images to:
# 1) nexus3.edgexfoundry.org:10004 with the `latest` tag
# 2) edgexfoundry dockerhub with the `latest` tag
# `release` will push docker images to:
# 1) nexus3.edgexfoundry.org:10002 with the `latest` tag and `VERSION` tag
# 2) edgexfoundry dockerhub with the `latest` tag and `VERSION` tag
#

"""
VERSION is set by reading the VERSION file in the project root.

We could then direct the blackbox tests against the staging repository 'latest' daily.  It might be helpful to interpolate the GIT_SHA into the tag for the staging repo images so we can trace back easier in the event of failure.
Thoughts?
Jeremy


Re: Docker publish conventions

Jeremy Phelps
 

I just thought of a blocker on SHA tag in staging for blackbox tests, not sure there would be a way to automate pulling those in.

On Thu, May 3, 2018 at 1:38 PM, <Trevor.Conn@...> wrote:

Works for me, and I agree "staging" should also have the SHA tag.


Trevor Conn
Senior Principal Software Engineer
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA

From: EdgeX-TSC-DevOps@lists.edgexfoundry.org <EdgeX-TSC-DevOps@lists.edgexfoundry.org> on behalf of Jeremy Phelps <jphelps@...>
Sent: Thursday, May 3, 2018 1:32 PM
To: edgex-tsc-devops@lists.edgexfoundry.org
Subject: [Edgex-tsc-devops] Docker publish conventions
 
Hi All,
I wanted to get some feed back on my following proposal for publishing docker images to the edgexfoundry docker registries:
"""
# DEPLOY_TYPE: Can be `snapshot`, `staging` or`release`
# `snapshot` will push docker images to:
# 1) nexus3.edgexfoundry.org:10003 with a GIT_SHA-VERSION tag
# `staging` will push docker images to:
# 1) nexus3.edgexfoundry.org:10004 with the `latest` tag
# 2) edgexfoundry dockerhub with the `latest` tag
# `release` will push docker images to:
# 1) nexus3.edgexfoundry.org:10002 with the `latest` tag and `VERSION` tag
# 2) edgexfoundry dockerhub with the `latest` tag and `VERSION` tag
#

"""
VERSION is set by reading the VERSION file in the project root.

We could then direct the blackbox tests against the staging repository 'latest' daily.  It might be helpful to interpolate the GIT_SHA into the tag for the staging repo images so we can trace back easier in the event of failure.
Thoughts?
Jeremy

Re: Docker publish conventions

Trevor.Conn@...
 

Works for me, and I agree "staging" should also have the SHA tag.


Trevor Conn
Senior Principal Software Engineer
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA


From: EdgeX-TSC-DevOps@... <EdgeX-TSC-DevOps@...> on behalf of Jeremy Phelps <jphelps@...>
Sent: Thursday, May 3, 2018 1:32 PM
To: edgex-tsc-devops@...
Subject: [Edgex-tsc-devops] Docker publish conventions
 
Hi All,
I wanted to get some feed back on my following proposal for publishing docker images to the edgexfoundry docker registries:
"""
# DEPLOY_TYPE: Can be `snapshot`, `staging` or`release`
# `snapshot` will push docker images to:
# 1) nexus3.edgexfoundry.org:10003 with a GIT_SHA-VERSION tag
# `staging` will push docker images to:
# 1) nexus3.edgexfoundry.org:10004 with the `latest` tag
# 2) edgexfoundry dockerhub with the `latest` tag
# `release` will push docker images to:
# 1) nexus3.edgexfoundry.org:10002 with the `latest` tag and `VERSION` tag
# 2) edgexfoundry dockerhub with the `latest` tag and `VERSION` tag
#

"""
VERSION is set by reading the VERSION file in the project root.

We could then direct the blackbox tests against the staging repository 'latest' daily.  It might be helpful to interpolate the GIT_SHA into the tag for the staging repo images so we can trace back easier in the event of failure.
Thoughts?
Jeremy

Docker publish conventions

Jeremy Phelps
 

Hi All,
I wanted to get some feed back on my following proposal for publishing docker images to the edgexfoundry docker registries:
"""
# DEPLOY_TYPE: Can be `snapshot`, `staging` or`release`
# `snapshot` will push docker images to:
# 1) nexus3.edgexfoundry.org:10003 with a GIT_SHA-VERSION tag
# `staging` will push docker images to:
# 1) nexus3.edgexfoundry.org:10004 with the `latest` tag
# 2) edgexfoundry dockerhub with the `latest` tag
# `release` will push docker images to:
# 1) nexus3.edgexfoundry.org:10002 with the `latest` tag and `VERSION` tag
# 2) edgexfoundry dockerhub with the `latest` tag and `VERSION` tag
#

"""
VERSION is set by reading the VERSION file in the project root.

We could then direct the blackbox tests against the staging repository 'latest' daily.  It might be helpful to interpolate the GIT_SHA into the tag for the staging repo images so we can trace back easier in the event of failure.
Thoughts?
Jeremy

[Jenkins] Build plugin for github repositories

popovych.andrey@...
 

Hi folks,

I'd like to propose jenkins plugin:
https://plugins.jenkins.io/embeddable-build-status

This one can embed build status in github project repose.
It can be useful for quick look whats going on with master.

Regards,
Andriy