Date   
Re: Stuck builds

Trevor.Conn@...
 

Dell Customer Communication

Hi Jeremy – We got a couple PRs through but the problem appears to be happening again. The following build has been running for about 1 hr 20 minutes:

 

https://jenkins.edgexfoundry.org/job/edgex-go-master-verify-go/254/

 

Trevor

 

From: edgex-tsc-devops-bounces@... [mailto:edgex-tsc-devops-bounces@...] On Behalf Of Jeremy Phelps
Sent: Wednesday, March 28, 2018 11:37 AM
To: edgex-tsc-devops@...
Subject: [Edgex-tsc-devops] Stuck builds

 

Hi All,
I'm currently investigating build timeout issues.  It looks like the timeouts are happening in the docker images while doing an apk update.  I also happened to notice that we had some "docker daily" jobs that had been running an unusually long time.  I killed all of those to clear the queue.

I am flying some today so will be unreachable until the evening but I have patches in the works that are currently being tested.  I will updated with results ASAP.

Thanks for your patience.

Jeremy

Reminder - Core WG meeting tomorrow at 10am CDT

James.White2@...
 

Dell - Internal Use - Confidential

The Core Working Group meeting tomorrow is at 10am CDT.  Topics for tomorrow's meeting include discussion on configuration standardization and Consul integration improvements for the Go code.  Find the agenda and connection information here:  https://wiki.edgexfoundry.org/display/FA/Core+Working+Group

 

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@...

 

Re: Stuck builds

Jeremy Phelps
 

Checking into it now.

On Thu, Mar 29, 2018 at 12:48 PM, <Trevor.Conn@...> wrote:

All of the daily builds appear to be hung. Can these be canceled so as to free up a build agent for PRs? I assume they're timing out on the Alpine Linux image source.


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

From: edgex-tsc-devops-bounces@lists.edgexfoundry.org <edgex-tsc-devops-bounces@lists.edgexfoundry.org> on behalf of Jeremy Phelps <jphelps@...>
Sent: Wednesday, March 28, 2018 11:36 AM
To: edgex-tsc-devops@lists.edgexfoundry.org
Subject: [Edgex-tsc-devops] Stuck builds
 
Hi All,
I'm currently investigating build timeout issues.  It looks like the timeouts are happening in the docker images while doing an apk update.  I also happened to notice that we had some "docker daily" jobs that had been running an unusually long time.  I killed all of those to clear the queue.
I am flying some today so will be unreachable until the evening but I have patches in the works that are currently being tested.  I will updated with results ASAP.
Thanks for your patience.
Jeremy

Re: Stuck builds

Jeremy Phelps
 

Ah yes those images also use the alpine image source, I'll need to update those as well.  I will cancel all of the daily jobs to free up the queue and unblock.  After that we will need to patch up the java service docker images.
Jeremy

On Thu, Mar 29, 2018 at 12:49 PM, Jeremy Phelps <jphelps@...> wrote:
Checking into it now.

On Thu, Mar 29, 2018 at 12:48 PM, <Trevor.Conn@...> wrote:

All of the daily builds appear to be hung. Can these be canceled so as to free up a build agent for PRs? I assume they're timing out on the Alpine Linux image source.


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

From: edgex-tsc-devops-bounces@lists.edgexfoundry.org <edgex-tsc-devops-bounces@lists.edgexfoundry.org> on behalf of Jeremy Phelps <jphelps@...>
Sent: Wednesday, March 28, 2018 11:36 AM
To: edgex-tsc-devops@...undry.org
Subject: [Edgex-tsc-devops] Stuck builds
 
Hi All,
I'm currently investigating build timeout issues.  It looks like the timeouts are happening in the docker images while doing an apk update.  I also happened to notice that we had some "docker daily" jobs that had been running an unusually long time.  I killed all of those to clear the queue.
I am flying some today so will be unreachable until the evening but I have patches in the works that are currently being tested.  I will updated with results ASAP.
Thanks for your patience.
Jeremy


Re: Stuck builds

Trevor.Conn@...
 

All of the daily builds appear to be hung. Can these be canceled so as to free up a build agent for PRs? I assume they're timing out on the Alpine Linux image source.


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


From: edgex-tsc-devops-bounces@... <edgex-tsc-devops-bounces@...> on behalf of Jeremy Phelps <jphelps@...>
Sent: Wednesday, March 28, 2018 11:36 AM
To: edgex-tsc-devops@...
Subject: [Edgex-tsc-devops] Stuck builds
 
Hi All,
I'm currently investigating build timeout issues.  It looks like the timeouts are happening in the docker images while doing an apk update.  I also happened to notice that we had some "docker daily" jobs that had been running an unusually long time.  I killed all of those to clear the queue.
I am flying some today so will be unreachable until the evening but I have patches in the works that are currently being tested.  I will updated with results ASAP.
Thanks for your patience.
Jeremy

Re: Stuck builds

Trevor.Conn@...
 

Many thanks!


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


From: Jeremy Phelps <jphelps@...>
Sent: Thursday, March 29, 2018 12:50 PM
To: Conn, Trevor
Cc: edgex-tsc-devops@...
Subject: Re: [Edgex-tsc-devops] Stuck builds
 
Ah yes those images also use the alpine image source, I'll need to update those as well.  I will cancel all of the daily jobs to free up the queue and unblock.  After that we will need to patch up the java service docker images.
Jeremy

On Thu, Mar 29, 2018 at 12:49 PM, Jeremy Phelps <jphelps@...> wrote:
Checking into it now.

On Thu, Mar 29, 2018 at 12:48 PM, <Trevor.Conn@...> wrote:

All of the daily builds appear to be hung. Can these be canceled so as to free up a build agent for PRs? I assume they're timing out on the Alpine Linux image source.


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

From: edgex-tsc-devops-bounces@lists.edgexfoundry.org <edgex-tsc-devops-bounces@lists.edgexfoundry.org> on behalf of Jeremy Phelps <jphelps@...>
Sent: Wednesday, March 28, 2018 11:36 AM
To: edgex-tsc-devops@...undry.org
Subject: [Edgex-tsc-devops] Stuck builds
 
Hi All,
I'm currently investigating build timeout issues.  It looks like the timeouts are happening in the docker images while doing an apk update.  I also happened to notice that we had some "docker daily" jobs that had been running an unusually long time.  I killed all of those to clear the queue.
I am flying some today so will be unreachable until the evening but I have patches in the works that are currently being tested.  I will updated with results ASAP.
Thanks for your patience.
Jeremy


Re: Stuck builds

Jeremy Phelps
 

I overlooked two spots yesterday and have a patch up covering them now at https://github.com/edgexfoundry/edgex-go/pull/95

On Wed, Mar 28, 2018 at 1:23 PM, <Trevor.Conn@...> wrote:

Dell Customer Communication

Hi Jeremy – We got a couple PRs through but the problem appears to be happening again. The following build has been running for about 1 hr 20 minutes:

 

https://jenkins.edgexfoundry.org/job/edgex-go-master-verify-go/254/

 

Trevor

 

From: edgex-tsc-devops-bounces@lists.edgexfoundry.org [mailto:edgex-tsc-devops-bounces@...] On Behalf Of Jeremy Phelps
Sent: Wednesday, March 28, 2018 11:37 AM
To: edgex-tsc-devops@lists.edgexfoundry.org
Subject: [Edgex-tsc-devops] Stuck builds

 

Hi All,
I'm currently investigating build timeout issues.  It looks like the timeouts are happening in the docker images while doing an apk update.  I also happened to notice that we had some "docker daily" jobs that had been running an unusually long time.  I killed all of those to clear the queue.

I am flying some today so will be unreachable until the evening but I have patches in the works that are currently being tested.  I will updated with results ASAP.

Thanks for your patience.

Jeremy


Read The Docs Account

Jeremy Phelps
 

Hi all,
I have set up the EdgeX account on https://readthedocs.org/ and grabbed a namespace for our documentation called "edgexfoundry".  Andy, if you can ping me with your read the docs username I can add you as a maintainer on that project.
Jeremy

Core Working Group Reminder - 10am CDT tomorrow

James.White2@...
 

Reminder, the EdgeX Core Working Group meets tomorrow at 10amCDT.  Find connection information and full agenda at:  https://wiki.edgexfoundry.org/display/FA/Core+Working+Group.  Tomorrow's topics include documentation move to GitHub, service naming/availability, providing guidance to the contributors on commit messaging and branch merging.

 

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@...

 

Core Working Group Meeting tomorrow at 10am CDT

James.White2@...
 

Reminder that the core working group meets tomorrow at 10am CDT.  Find the agenda and connection information here:  https://wiki.edgexfoundry.org/display/FA/Core+Working+Group.  It is a full agenda with major topics to include:  GitHub Docs availability, Core Service Refactor in support of resource loose coupling and more unit testing, DS Requirements issue clean up, and finalization of the service naming/availability design.

 

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@...

 

EdgeX Documentation Preview

Andrew Foster <andy@...>
 

Dear EdgeX community,

 

As part of the forthcoming California release it was decided that the existing product level content from the Wiki and any new content generated to support the release would be converted into a format (we decided on reStructuredText - reST) that enables this information to live alongside the code and be managed from the EdgeX Foundry GitHub repository.

 

The initial work to support the work has now been completed, although we are still improving and tidying up the content as we head towards the California release.

 

The new documentation can be accessed at https://github.com/edgexfoundry/edgex-go/tree/master/docs. Once you have cloned the edgex-go repository you can simply build the documentation by running $ . build.sh from the /docs directory.

 

The source reST and graphics files are held in individual directories underneath the /docs directory.

 

We have also hosted a generated HTML version of EdgeX Documentation at  https://www.iotechsys.com/cmsfiles/iotech_systems/docs/html/index.html it you don’t want to build your own local copy of the documentation then this is the best place to start.

 

We would welcome feedback on the new documentation and if you spot any typos, bad formatting etc. then you can simply report it to me (andy@...) to start with or alternatively add an Issue to GitHub and assign it to me (andyf1967).

 

Regards,

 

Andy

 

Product Director

Tel: +44 (0)7703 006 379

 

Re: [Edgex-tsc-security] EdgeX Documentation Preview

Drasko DRASKOVIC <drasko@...>
 

Interestingly enough, works on ReadTheDocs practically out of the box:
http://edgex-foundry.readthedocs.io

At least first two chapters, then it got lost :)

I just pointed ReadTheDocs to our repo, this is what it produced. I'd
have to see if some additional tweaks are needed and how to tell RDD
to use it's own template, not this white one...

Best regards,
Drasko

On Tue, Apr 17, 2018 at 11:41 AM, Andrew Foster <andy@...> wrote:
Dear EdgeX community,



As part of the forthcoming California release it was decided that the
existing product level content from the Wiki and any new content generated
to support the release would be converted into a format (we decided on
reStructuredText - reST) that enables this information to live alongside the
code and be managed from the EdgeX Foundry GitHub repository.



The initial work to support the work has now been completed, although we are
still improving and tidying up the content as we head towards the California
release.



The new documentation can be accessed at
https://github.com/edgexfoundry/edgex-go/tree/master/docs. Once you have
cloned the edgex-go repository you can simply build the documentation by
running $ . build.sh from the /docs directory.



The source reST and graphics files are held in individual directories
underneath the /docs directory.



We have also hosted a generated HTML version of EdgeX Documentation at
https://www.iotechsys.com/cmsfiles/iotech_systems/docs/html/index.html it
you don’t want to build your own local copy of the documentation then this
is the best place to start.



We would welcome feedback on the new documentation and if you spot any
typos, bad formatting etc. then you can simply report it to me
(andy@...) to start with or alternatively add an Issue to GitHub
and assign it to me (andyf1967).



Regards,



Andy



Product Director

Tel: +44 (0)7703 006 379



--
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Re: [Edgex-tsc-security] EdgeX Documentation Preview

Andrew Foster <andy@...>
 

Drasko,

It might be hierarchy that confuses it. Also there is a step in the build process to run raml2html and incorporate the generate HTML into the overall set of HTML. No idea how ReadTheDocs would deal with that (haven't had a chance to investigate).

Regards,

Andy

-----Original Message-----
From: Drasko DRASKOVIC <drasko@...>
Sent: Tuesday, April 17, 2018 12:57 PM
To: Andrew Foster <andy@...>
Cc: edgex-tsc-core@...; edgex-tsc-qa-test@...; edgex-tsc-security@...; edgex-tsc-systems-mgmt@...; edgex-tsc-devops@...
Subject: Re: [Edgex-tsc-security] EdgeX Documentation Preview

Interestingly enough, works on ReadTheDocs practically out of the box:
http://edgex-foundry.readthedocs.io

At least first two chapters, then it got lost :)

I just pointed ReadTheDocs to our repo, this is what it produced. I'd have to see if some additional tweaks are needed and how to tell RDD to use it's own template, not this white one...

Best regards,
Drasko






On Tue, Apr 17, 2018 at 11:41 AM, Andrew Foster <andy@...> wrote:
Dear EdgeX community,



As part of the forthcoming California release it was decided that the
existing product level content from the Wiki and any new content
generated to support the release would be converted into a format (we
decided on reStructuredText - reST) that enables this information to
live alongside the code and be managed from the EdgeX Foundry GitHub repository.



The initial work to support the work has now been completed, although
we are still improving and tidying up the content as we head towards
the California release.



The new documentation can be accessed at
https://github.com/edgexfoundry/edgex-go/tree/master/docs. Once you
have cloned the edgex-go repository you can simply build the
documentation by running $ . build.sh from the /docs directory.



The source reST and graphics files are held in individual directories
underneath the /docs directory.



We have also hosted a generated HTML version of EdgeX Documentation at
https://www.iotechsys.com/cmsfiles/iotech_systems/docs/html/index.html
it you don’t want to build your own local copy of the documentation
then this is the best place to start.



We would welcome feedback on the new documentation and if you spot any
typos, bad formatting etc. then you can simply report it to me
(andy@...) to start with or alternatively add an Issue to
GitHub and assign it to me (andyf1967).



Regards,



Andy



Product Director

Tel: +44 (0)7703 006 379





--
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Core WG meeting tomorrow at 10am CDT

James.White2@...
 

Reminder - there WILL BE a core working group meeting tomorrow at 10am CDT.  Please see here: https://wiki.edgexfoundry.org/display/FA/Core+Working+Group for connection details and agenda.  Major topic this week will be technical debt items and upcoming F2F architectural topics.

 

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@...

 

[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

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

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

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

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

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