Date   
Re: Gofmt git commit hook

Trevor.Conn@...
 

Dell - Internal Use - Confidential

Thanks, Jeremy. It looks like the git-hooks utility you linked to below would allow us to create a git-hooks directory in our repo and then put the appropriate scripts in there. This would allow us to source control the scripts.

 

It also looks like their “community hooks” would allow us to create a repo specifically for githook scripts. Then all we’d have to include in our projects is a githooks.json file like this one. Execution requires internet connectivity though, obviously.

 

We’d need to require all developers to install the utility if we go down this route.

 

Trevor

 

From: EdgeX-TSC-DevOps@... [mailto:EdgeX-TSC-DevOps@...] On Behalf Of Jeremy Phelps
Sent: Friday, June 15, 2018 1:10 PM
To: Conn, Trevor
Cc: EdgeX-TSC-DevOps@...; EdgeX-GoLang@...
Subject: Re: [Edgex-tsc-devops] Gofmt git commit hook

 

Hi Trevor,

I am in favor of something like this generally.  I think because we use GitHub we will have to have client side hooks ( I will look into it further though ).  There are tools available to help share commit hook scripts such as https://github.com/git-hooks/git-hooks/wiki/Get-Started.  Lets put this on the table for discussion, we can ramp up the DevOps WG meetings again if we need extra time.

Jeremy

 

On Fri, Jun 15, 2018 at 12:12 PM, <Trevor.Conn@...> wrote:

https://tip.golang.org/misc/git/pre-commit

 

Per our discussion in the Core WG call yesterday, I’m working today on looking for code quality tools that we can easily integrate and that will do as many of the required checks prior to merge as possible. I found the above git pre-commit script which can be used to run gofmt prior to commit on the client side. Sample output for poorly formatted code when I try to commit looks like this:

 

Go files must be formatted with gofmt. Please run:

  gofmt -w /Users/tconn/go/src/github.com/edgexfoundry/edgex-go/cmd/core-data/main.go

 

I can't commit until I fix the problems. The only downside, as I understand it, is that it relies on the developer to create the scripts and give it execute permissions. Plus I don’t understand how this can be source controlled. It looks like there are server-side git hooks as well.

 

https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

 

Would this be more appropriate as a server-side hook that runs during a push? If so, what’s the effort in setting that up in all Go repos? How about when we create new Go repos?

 

The script is linked from a larger blog post:

https://blog.golang.org/go-fmt-your-code

 

Using this strategy we could also wire in golint and other tools. Thoughts?

 

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

 

California Branch cutting

Jeremy Phelps
 

Hello All,
I am ready to proceed with the California branch cutting for our upcoming release but we can hold off on it a bit for folks to get last minute features in.  This will minimize folks having to commit to one branch and also cherry pick into another (at least for now as this is always a possibility).
Please respond if you would like extra time to get changes in.
Jeremy

Re: Gofmt git commit hook

Jeremy Phelps
 

Hi Trevor,
I am in favor of something like this generally.  I think because we use GitHub we will have to have client side hooks ( I will look into it further though ).  There are tools available to help share commit hook scripts such as https://github.com/git-hooks/git-hooks/wiki/Get-Started.  Lets put this on the table for discussion, we can ramp up the DevOps WG meetings again if we need extra time.
Jeremy

On Fri, Jun 15, 2018 at 12:12 PM, <Trevor.Conn@...> wrote:

https://tip.golang.org/misc/git/pre-commit

 

Per our discussion in the Core WG call yesterday, I’m working today on looking for code quality tools that we can easily integrate and that will do as many of the required checks prior to merge as possible. I found the above git pre-commit script which can be used to run gofmt prior to commit on the client side. Sample output for poorly formatted code when I try to commit looks like this:

 

Go files must be formatted with gofmt. Please run:

  gofmt -w /Users/tconn/go/src/github.com/edgexfoundry/edgex-go/cmd/core-data/main.go

 

I can't commit until I fix the problems. The only downside, as I understand it, is that it relies on the developer to create the scripts and give it execute permissions. Plus I don’t understand how this can be source controlled. It looks like there are server-side git hooks as well.

 

https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

 

Would this be more appropriate as a server-side hook that runs during a push? If so, what’s the effort in setting that up in all Go repos? How about when we create new Go repos?

 

The script is linked from a larger blog post:

https://blog.golang.org/go-fmt-your-code


Using this strategy we could also wire in golint and other tools. Thoughts?


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


Gofmt git commit hook

Trevor.Conn@...
 

https://tip.golang.org/misc/git/pre-commit

 

Per our discussion in the Core WG call yesterday, I’m working today on looking for code quality tools that we can easily integrate and that will do as many of the required checks prior to merge as possible. I found the above git pre-commit script which can be used to run gofmt prior to commit on the client side. Sample output for poorly formatted code when I try to commit looks like this:

 

Go files must be formatted with gofmt. Please run:

  gofmt -w /Users/tconn/go/src/github.com/edgexfoundry/edgex-go/cmd/core-data/main.go

 

I can't commit until I fix the problems. The only downside, as I understand it, is that it relies on the developer to create the scripts and give it execute permissions. Plus I don’t understand how this can be source controlled. It looks like there are server-side git hooks as well.

 

https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

 

Would this be more appropriate as a server-side hook that runs during a push? If so, what’s the effort in setting that up in all Go repos? How about when we create new Go repos?

 

The script is linked from a larger blog post:

https://blog.golang.org/go-fmt-your-code


Using this strategy we could also wire in golint and other tools. Thoughts?


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

Re: ARM Builder Issues

Fede Claramonte <fclaramonte@...>
 

Thunderx and the recently released thunderx2 are the 'big brothers' of the board currently used(octeontx). The thunderx are better suited for being a jenkins build machine, so great news.

In the meanwhile, we will continue debugging the networks problems. One of the solutions we are thinking is about adding a second build machine.

And if anyone is interested in hosting the build machine we can donate a board so we don't need to host our self.

Fede

PD: It is better to contact Chencho (in CC) for issues with the jenkins build machine.



On 06/11/2018 09:12 PM, Trevor.Conn@... wrote:

Dell Customer Communication

Whatever it is, I like the name!

 

From: EdgeX-TSC-DevOps@... [mailto:EdgeX-TSC-DevOps@...] On Behalf Of Jeremy Phelps
Sent: Monday, June 11, 2018 12:56 PM
To: Conn, Trevor
Cc: edgex-tsc-devops@...; Fede Claramonte
Subject: Re: [Edgex-tsc-devops] ARM Builder Issues

 

I recently got word that our provider is adding ARM soon.  They are apparently adding "thunderx" machines, thought I don't have any more specifics atm.  Fede, are

you familiar with thunderx?

Jeremy

 

On Sun, Jun 10, 2018 at 7:49 PM, <Trevor.Conn@...> wrote:

Dell Customer Communication

https://github.com/edgexfoundry/edgex-go/pull/292

 

The ARM builder is unable to pull down code from Git due to network issues. From the logs:

 

https://logs.edgexfoundry.org/production/vex-yul-edgex-jenkins-1/edgex-go-master-verify-go-arm/540/console.log.gz

 

Receiving objects:  11% (1328/11315), 8.34 MiB | 16.00 KiB/s  

fatal: The remote end hung up unexpectedly

fatal: early EOF

fatal: index-pack failed

at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2002)

 

What would an alternate solution for building our code for ARM look like? It seems like we run into network connectivity problems a lot, and it would be nice to be able to run more than 1 job at a time.

 

Trevor Conn

Senior Principal Software Engineer

Dell Technologies | IoT DellTech

Trevor.Conn@...

Round Rock, TX USA

 

 


Re: ARM Builder Issues

Trevor.Conn@...
 

Dell Customer Communication

Whatever it is, I like the name!

 

From: EdgeX-TSC-DevOps@... [mailto:EdgeX-TSC-DevOps@...] On Behalf Of Jeremy Phelps
Sent: Monday, June 11, 2018 12:56 PM
To: Conn, Trevor
Cc: edgex-tsc-devops@...; Fede Claramonte
Subject: Re: [Edgex-tsc-devops] ARM Builder Issues

 

I recently got word that our provider is adding ARM soon.  They are apparently adding "thunderx" machines, thought I don't have any more specifics atm.  Fede, are

you familiar with thunderx?

Jeremy

 

On Sun, Jun 10, 2018 at 7:49 PM, <Trevor.Conn@...> wrote:

Dell Customer Communication

https://github.com/edgexfoundry/edgex-go/pull/292

 

The ARM builder is unable to pull down code from Git due to network issues. From the logs:

 

https://logs.edgexfoundry.org/production/vex-yul-edgex-jenkins-1/edgex-go-master-verify-go-arm/540/console.log.gz

 

Receiving objects:  11% (1328/11315), 8.34 MiB | 16.00 KiB/s  

fatal: The remote end hung up unexpectedly

fatal: early EOF

fatal: index-pack failed

at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2002)

 

What would an alternate solution for building our code for ARM look like? It seems like we run into network connectivity problems a lot, and it would be nice to be able to run more than 1 job at a time.

 

Trevor Conn

Senior Principal Software Engineer

Dell Technologies | IoT DellTech

Trevor.Conn@...

Round Rock, TX USA

 

 

Re: ARM Builder Issues

Jeremy Phelps
 

I recently got word that our provider is adding ARM soon.  They are apparently adding "thunderx" machines, thought I don't have any more specifics atm.  Fede, are
you familiar with thunderx?
Jeremy

On Sun, Jun 10, 2018 at 7:49 PM, <Trevor.Conn@...> wrote:

Dell Customer Communication

https://github.com/edgexfoundry/edgex-go/pull/292

 

The ARM builder is unable to pull down code from Git due to network issues. From the logs:

 

https://logs.edgexfoundry.org/production/vex-yul-edgex-jenkins-1/edgex-go-master-verify-go-arm/540/console.log.gz

 

Receiving objects:  11% (1328/11315), 8.34 MiB | 16.00 KiB/s  

fatal: The remote end hung up unexpectedly

fatal: early EOF

fatal: index-pack failed

at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2002)

 

What would an alternate solution for building our code for ARM look like? It seems like we run into network connectivity problems a lot, and it would be nice to be able to run more than 1 job at a time.

 

Trevor Conn

Senior Principal Software Engineer

Dell Technologies | IoT DellTech

Trevor.Conn@...

Round Rock, TX USA

 


ARM Builder Issues

Trevor.Conn@...
 

Dell Customer Communication

https://github.com/edgexfoundry/edgex-go/pull/292

 

The ARM builder is unable to pull down code from Git due to network issues. From the logs:

 

https://logs.edgexfoundry.org/production/vex-yul-edgex-jenkins-1/edgex-go-master-verify-go-arm/540/console.log.gz

 

Receiving objects:  11% (1328/11315), 8.34 MiB | 16.00 KiB/s  

fatal: The remote end hung up unexpectedly

fatal: early EOF

fatal: index-pack failed

at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2002)

 

What would an alternate solution for building our code for ARM look like? It seems like we run into network connectivity problems a lot, and it would be nice to be able to run more than 1 job at a time.

 

Trevor Conn

Senior Principal Software Engineer

Dell Technologies | IoT DellTech

Trevor.Conn@...

Round Rock, TX USA

 

CI documentation

Jeremy Phelps
 

Hi All,
The RELENG team has been putting together some docs to help projects better understand how CI works generally. 
This covers how to configure things and more specifically for project participants, how to configure a sandbox job should you ever wish to build out a CI job.
Note that anyone can contribute to CI by submitted a PR to https://github.com/edgexfoundry/ci-management
If you have any questions about the process and/or documentation please reach out to me.
Jeremy

Core WG meeting tomorrow (5/31) at 10am CDT

James.White2@...
 

Dell - Internal Use - Confidential

All, reminder that we’ll have our core working group meeting tomorrow at 10am central time.  Agenda and connection information available 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: Recent nexus3 upgrade

James.White2@...
 

Dell - Internal Use - Confidential

Great stuff Jeremy – this will help eliminate several issues that inevitably arise with compose file and Nexus.

 

From: EdgeX-TSC-DevOps@... [mailto:EdgeX-TSC-DevOps@...] On Behalf Of Jeremy Phelps
Sent: Wednesday, May 30, 2018 7:54 AM
To: edgex-tsc-devops@...
Subject: [Edgex-tsc-devops] Recent nexus3 upgrade

 

Hi All,

With the recent nexus3.edgexfoundry.org upgrade, we now have true anonymous docker pulls available.  You no longer have to do `docker login nexus3.edgexfoundry.org:10004` to pull images from staging for example.

Jeremy

Recent nexus3 upgrade

Jeremy Phelps
 

Hi All,
With the recent nexus3.edgexfoundry.org upgrade, we now have true anonymous docker pulls available.  You no longer have to do `docker login nexus3.edgexfoundry.org:10004` to pull images from staging for example.
Jeremy

Re: [Edgex-devel] Scheduled Maintenance on May 25th, 2018

Jeremy Phelps
 

The systems maintenance is now complete.

On Fri, May 25, 2018 at 2:56 PM, Jeremy Phelps <jphelps@...> wrote:
This Maintenance will start in 5 minutes.

On Fri, May 25, 2018 at 8:23 AM, Jeremy Phelps <jphelps@...> wrote:
Hi All,
Just a reminder that this maintenance is scheduled to happen today at 1pm-3pm PDT.
Jeremy

On Fri, May 18, 2018 at 12:19 PM, Jeremy Phelps <jphelps@...> wrote:
HI All,
The Linux Foundation will be performing system maintenance on EdgeX Systems.


Systems Affected:

Schedule:
    Systems will be generally unavailable:
    May 25th, 2018 from 1pm - 3pm PDT

Why:
    This maintenance will include necessary upgrades for applications as well
     as system level operating system updates.




Re: [Edgex-devel] Scheduled Maintenance on May 25th, 2018

Jeremy Phelps
 

This Maintenance will start in 5 minutes.

On Fri, May 25, 2018 at 8:23 AM, Jeremy Phelps <jphelps@...> wrote:
Hi All,
Just a reminder that this maintenance is scheduled to happen today at 1pm-3pm PDT.
Jeremy

On Fri, May 18, 2018 at 12:19 PM, Jeremy Phelps <jphelps@...> wrote:
HI All,
The Linux Foundation will be performing system maintenance on EdgeX Systems.


Systems Affected:

Schedule:
    Systems will be generally unavailable:
    May 25th, 2018 from 1pm - 3pm PDT

Why:
    This maintenance will include necessary upgrades for applications as well
     as system level operating system updates.



Re: [Edgex-devel] Scheduled Maintenance on May 25th, 2018

Jeremy Phelps
 

Hi All,
Just a reminder that this maintenance is scheduled to happen today at 1pm-3pm PDT.
Jeremy

On Fri, May 18, 2018 at 12:19 PM, Jeremy Phelps <jphelps@...> wrote:
HI All,
The Linux Foundation will be performing system maintenance on EdgeX Systems.


Systems Affected:

Schedule:
    Systems will be generally unavailable:
    May 25th, 2018 from 1pm - 3pm PDT

Why:
    This maintenance will include necessary upgrades for applications as well
     as system level operating system updates.


DevOps WG voter list

James.White2@...
 

Members and followers of the EdgeX Foundry DevOps Working Group,

 

We are entering into the TSC election process.  As such, we need to prepare and present our contributors voting roster to the community in preparation for elections.  The list below contains the names of our current DevOps working group contributors who have voting rights to help elect the next WG chairperson. “Contributors” under the charter of EdgeX includes contributors of code as well as documentation and other artifacts.  Based on the current EdgeX GitHub and Wiki site, the following people are currently listed as contributors to the DevOps working group area:

 

 

 

DevOps WG

Contribution Repos

Other Rationale

Andrew Grimberg

ci-management

chadyoungdell

developer-scripts

chencho, sergio.munoz

developer-scripts

Federico Claramonte

developer-scripts

Huaqiao Zhang

developer-scripts

Jeremy Phelps

ci-management

Jim White

developer-scripts

Konrad Zapalowicz

developer-scripts

steve osselton

docker-edgex-mongo

Thanh Ha

ci-management

Trevor Conn

developer-scripts

Tyler Cox

developer-scripts

YANG YOU SUNG

developer-scripts

 

 

 

 

 

If you feel you should also have voting rights in this working group and do not find your name on the list above, please respond to this message with an indication of your contribution that you believe applies prior to  June 4th.  The schedule for TSC nominations and elections is below.

 

·         Now - Monday, June 4: Establish list of Contributors, WG Chair Nominations and Voting

·         Friday, June 1 - Friday, June 8: TSC At-large Nominations

·         Monday, June 4: WG Chairs for new term named

·         Tuesday, June 5 - Wednesday, June 6: TSC F2F Meeting (Palo Alto)

·         Friday, June 8 - Friday, June 15: TSC At-large Elections

·         Monday, June 18 - Friday, June 22: TSC Chair Nominations

·         Sunday, June 24: End of current TSC term

·         Monday, June 25: 1st day of new TSC

·         Monday, June 25 - Friday, June 29: TSC Chair Voting

 

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 tomorrow at 10am CDT

James.White2@...
 

Dell - Internal Use - Confidential

Hello again everyone. A reminder that the Core working group will meet tomorrow at 10am Central time. The connection information and full agenda can be found here: https://wiki.edgexfoundry.org/display/FA/Core+Working+Group.


There is plenty to discuss tomorrow to include: working group chairman nominations, finalizing the upcoming TSC F2F agenda, a proposed revision around reviewing and accepting code PRs, and a new export service design idea for Delhi. Hope you can join us.

 

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

 

Scheduled Maintenance on May 25th, 2018

Jeremy Phelps
 

HI All,
The Linux Foundation will be performing system maintenance on EdgeX Systems.


Systems Affected:

Schedule:
    Systems will be generally unavailable:
    May 25th, 2018 from 1pm - 3pm PDT

Why:
    This maintenance will include necessary upgrades for applications as well
     as system level operating system updates.

Re: Publishing docs

Steve Osselton <steve@...>
 

Hi Jeremy,

Have a look in edgex-go repository in the docs, sub directory. The build.sh script should
build the documentation (using a docker container) into the _build sub directory that is
mounted as a volume into the container. Look at build.sh, Dockerfile.build and entrypoint.sh.
You should just be able to:

cd docs
./build.sh

Should be straight forward to integrate this with CI.

Let me know of any questions, problems etc.

Cheers Steve.


On 17 May 2018 at 16:49, Jeremy Phelps <jphelps@...> wrote:
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



--
Technical Director
IOTech Systems Ltd.

Re: Publishing docs

Jeremy Phelps
 

Perfect, thanks Steve.
Jeremy

On Thu, May 17, 2018 at 10:56 AM, Steve Osselton <steve@...> wrote:
Hi Jeremy,

Have a look in edgex-go repository in the docs, sub directory. The build.sh script should
build the documentation (using a docker container) into the _build sub directory that is
mounted as a volume into the container. Look at build.sh, Dockerfile.build and entrypoint.sh.
You should just be able to:

cd docs
./build.sh

Should be straight forward to integrate this with CI.

Let me know of any questions, problems etc.

Cheers Steve.


On 17 May 2018 at 16:49, Jeremy Phelps <jphelps@...> wrote:
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



--
Technical Director
IOTech Systems Ltd.