Date   
Re: [Edgex-devel] Emergency Jenkins Maintenance

Trevor.Conn@...
 

Dell Customer Communication

Running now. Thanks!

 

From: EdgeX-Devel@... [mailto:EdgeX-Devel@...] On Behalf Of Jeremy Phelps
Sent: Wednesday, July 11, 2018 8:18 PM
To: Conn, Trevor
Cc: edgex-devel@...; edgex-tsc-devops@...
Subject: Re: [Edgex-devel] Emergency Jenkins Maintenance

 

Taking a look again.

 

On Wed, Jul 11, 2018, 20:01 <Trevor.Conn@...> wrote:

Dell Customer Communication

Hi Jeremy – Looks like they might be stuck. There have been 10 in the queue for about an hour, no running agents.

 

Trevor

 

From: EdgeX-Devel@... [mailto:EdgeX-Devel@...] On Behalf Of Jeremy Phelps
Sent: Wednesday, July 11, 2018 6:57 PM
To: edgex-devel@...; edgex-tsc-devops@...
Subject: Re: [Edgex-devel] Emergency Jenkins Maintenance

 

Build on Jenkins are executing again.

 

On Wed, Jul 11, 2018 at 6:35 PM, Jeremy Phelps <jphelps@...> wrote:

htps://jenkins.edgexfoundry.org is down for a moment while I resolve a plugin incompatibility.

I appreciate your patience.

I will update when it is operational again.

 

 

Re: [Edgex-devel] Emergency Jenkins Maintenance

Jeremy Phelps
 

Taking a look again.


On Wed, Jul 11, 2018, 20:01 <Trevor.Conn@...> wrote:

Dell Customer Communication

Hi Jeremy – Looks like they might be stuck. There have been 10 in the queue for about an hour, no running agents.

 

Trevor

 

From: EdgeX-Devel@... [mailto:EdgeX-Devel@...] On Behalf Of Jeremy Phelps
Sent: Wednesday, July 11, 2018 6:57 PM
To: edgex-devel@...; edgex-tsc-devops@...
Subject: Re: [Edgex-devel] Emergency Jenkins Maintenance

 

Build on Jenkins are executing again.

 

On Wed, Jul 11, 2018 at 6:35 PM, Jeremy Phelps <jphelps@...> wrote:

htps://jenkins.edgexfoundry.org is down for a moment while I resolve a plugin incompatibility.

I appreciate your patience.

I will update when it is operational again.

 

 

Re: [Edgex-devel] Emergency Jenkins Maintenance

Trevor.Conn@...
 

Dell Customer Communication

Hi Jeremy – Looks like they might be stuck. There have been 10 in the queue for about an hour, no running agents.

 

Trevor

 

From: EdgeX-Devel@... [mailto:EdgeX-Devel@...] On Behalf Of Jeremy Phelps
Sent: Wednesday, July 11, 2018 6:57 PM
To: edgex-devel@...; edgex-tsc-devops@...
Subject: Re: [Edgex-devel] Emergency Jenkins Maintenance

 

Build on Jenkins are executing again.

 

On Wed, Jul 11, 2018 at 6:35 PM, Jeremy Phelps <jphelps@...> wrote:

htps://jenkins.edgexfoundry.org is down for a moment while I resolve a plugin incompatibility.

I appreciate your patience.

I will update when it is operational again.

 

 

Re: [Edgex-devel] Emergency Jenkins Maintenance

Jeremy Phelps
 

Build on Jenkins are executing again.

On Wed, Jul 11, 2018 at 6:35 PM, Jeremy Phelps <jphelps@...> wrote:
htps://jenkins.edgexfoundry.org is down for a moment while I resolve a plugin incompatibility.
I appreciate your patience.
I will update when it is operational again.


Emergency Jenkins Maintenance

Jeremy Phelps
 

htps://jenkins.edgexfoundry.org is down for a moment while I resolve a plugin incompatibility.
I appreciate your patience.
I will update when it is operational again.

Re: DevOps Meetings

Michael Hall
 

Those time work for me, please add me to the invite.


On 07/10/2018 10:26 PM, Jeremy Phelps wrote:
We are in need to set up the DevOps meeting again in order to plan more appropriately.  I am proposing a meeting time of 1pm-2pm Central Time on Monday's but want to get feedback from those interested in attending.

Some initial topics to discuss will be:
1) Developer Workflow (this will affect everyone)
2) Enhanced integration test
3) Release automation (to include branch cutting and versioning strategy)
4) Long running Jenkins job that runs EdgeX in a distributed environment using HEAT templates.
5) Planning around supported docker-compose formats
6) Deprecation of java services

Once we agree on a time I will start a deck and share with the meeting invite.

Jeremy
-- 
Michael Hall
Contractor, The Linux Foundation

Re: DevOps Meetings

Trevor.Conn@...
 

Dell Customer Communication

1-2PM Central time on Monday works for me!

 

Trevor

 

From: EdgeX-TSC-DevOps@... [mailto:EdgeX-TSC-DevOps@...] On Behalf Of Jeremy Phelps
Sent: Tuesday, July 10, 2018 9:26 PM
To: edgex-tsc-devops@...
Subject: [Edgex-tsc-devops] DevOps Meetings

 

We are in need to set up the DevOps meeting again in order to plan more appropriately.  I am proposing a meeting time of 1pm-2pm Central Time on Monday's but want to get feedback from those interested in attending.

 

Some initial topics to discuss will be:

1) Developer Workflow (this will affect everyone)

2) Enhanced integration test

3) Release automation (to include branch cutting and versioning strategy)

4) Long running Jenkins job that runs EdgeX in a distributed environment using HEAT templates.

5) Planning around supported docker-compose formats

6) Deprecation of java services

 

Once we agree on a time I will start a deck and share with the meeting invite.

 

Jeremy

Re: DevOps Meetings

James.White2@...
 

+1 – please invite me

 

From: EdgeX-TSC-DevOps@... [mailto:EdgeX-TSC-DevOps@...] On Behalf Of Jeremy Phelps
Sent: Tuesday, July 10, 2018 9:26 PM
To: edgex-tsc-devops@...
Subject: [Edgex-tsc-devops] DevOps Meetings

 

We are in need to set up the DevOps meeting again in order to plan more appropriately.  I am proposing a meeting time of 1pm-2pm Central Time on Monday's but want to get feedback from those interested in attending.

 

Some initial topics to discuss will be:

1) Developer Workflow (this will affect everyone)

2) Enhanced integration test

3) Release automation (to include branch cutting and versioning strategy)

4) Long running Jenkins job that runs EdgeX in a distributed environment using HEAT templates.

5) Planning around supported docker-compose formats

6) Deprecation of java services

 

Once we agree on a time I will start a deck and share with the meeting invite.

 

Jeremy

DevOps Meetings

Jeremy Phelps
 

We are in need to set up the DevOps meeting again in order to plan more appropriately.  I am proposing a meeting time of 1pm-2pm Central Time on Monday's but want to get feedback from those interested in attending.

Some initial topics to discuss will be:
1) Developer Workflow (this will affect everyone)
2) Enhanced integration test
3) Release automation (to include branch cutting and versioning strategy)
4) Long running Jenkins job that runs EdgeX in a distributed environment using HEAT templates.
5) Planning around supported docker-compose formats
6) Deprecation of java services

Once we agree on a time I will start a deck and share with the meeting invite.

Jeremy

Re: Delhi release version

Trevor.Conn@...
 

Dell Customer Communication

But Jeremy, we discussed during the California release that going forward we would tag the master branch version as “master”. This tag would flow through to Docker Hub and would make our daily builds available via that tag. Couldn’t blackbox tests in the master branch then always target the master tag? Same for California and eventually Delhi?

 

Trevor

 

From: White2, James
Sent: Monday, July 9, 2018 9:25 PM
To: Jeremy Phelps
Cc: Conn, Trevor; EdgeX-TSC-DevOps@...
Subject: RE: [Edgex-tsc-devops] Delhi release version

 

Ah – in that case… bump away.

 

From: Jeremy Phelps [mailto:jphelps@...]
Sent: Monday, July 09, 2018 9:23 PM
To: White2, James
Cc: Conn, Trevor; EdgeX-TSC-DevOps@...
Subject: Re: [Edgex-tsc-devops] Delhi release version

 

Building the artifacts with specified versions is different from git tagging.  The reason we want to bump the version on master before the release is for the daily staging jobs mostly.  We will be pointing blackbox tests at these, and to avoid confusion they should be different than our barcelona versions since they are already released.  Daily builds will of course overwrite but it's easier to reason about if we do bump.

 

 

On Mon, Jul 9, 2018 at 9:15 PM, <James.White2@...> wrote:

I am not sure we know what version number to give Delhi yet.  I’d like to think it might actually be 1.0, but too soon to label it at this time. 

Is it important to tag the branch now versus when we cut a release?  I don’t recall having to tag at the start of a release before.

 

Is there a reason we are tagging at the start of a release versus at the end?

 

From: Jeremy Phelps [mailto:jphelps@...]
Sent: Monday, July 09, 2018 4:22 PM
To: Conn, Trevor
Cc: EdgeX-TSC-DevOps@...; White2, James
Subject: Re: [Edgex-tsc-devops] Delhi release version

 

If we have the version for Delhi in the master branch already then we don't have that work to do after the cut.  The only work will be updating master again to the next release version.

 

On Mon, Jul 9, 2018 at 4:16 PM, <Trevor.Conn@...> wrote:

Hi Jeremy -- When you say "master" tag will hurt us, how do you mean? Wouldn't we just make a change to the desired version in the Delhi branch after the cut?

 

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: Monday, July 9, 2018 4:09 PM
To: edgex-tsc-devops@...; White2, James; Conn, Trevor
Subject: [Edgex-tsc-devops] Delhi release version

 

Hi I'd like to bump the version on master branch for the Delhi release.  I talked with Trevor a bit about just calling it "master" but that will hurt us come time to cut the branch.

Are we shooting for 0.7.0?

Jeremy

 

 

Re: Delhi release version

Jeremy Phelps
 

We did discuss that, but then it felt wrong to me.  Let me draw up some processes to discuss during a newly formed DevOps meeting so we can hammer it out.

On Mon, Jul 9, 2018 at 9:27 PM, <Trevor.Conn@...> wrote:

Dell Customer Communication

But Jeremy, we discussed during the California release that going forward we would tag the master branch version as “master”. This tag would flow through to Docker Hub and would make our daily builds available via that tag. Couldn’t blackbox tests in the master branch then always target the master tag? Same for California and eventually Delhi?

 

Trevor

 

From: White2, James
Sent: Monday, July 9, 2018 9:25 PM
To: Jeremy Phelps
Cc: Conn, Trevor; EdgeX-TSC-DevOps@lists.edgexfoundry.org
Subject: RE: [Edgex-tsc-devops] Delhi release version

 

Ah – in that case… bump away.

 

From: Jeremy Phelps [mailto:jphelps@linuxfoundation.org]
Sent: Monday, July 09, 2018 9:23 PM
To: White2, James
Cc: Conn, Trevor; EdgeX-TSC-DevOps@lists.edgexfoundry.org
Subject: Re: [Edgex-tsc-devops] Delhi release version

 

Building the artifacts with specified versions is different from git tagging.  The reason we want to bump the version on master before the release is for the daily staging jobs mostly.  We will be pointing blackbox tests at these, and to avoid confusion they should be different than our barcelona versions since they are already released.  Daily builds will of course overwrite but it's easier to reason about if we do bump.

 

 

On Mon, Jul 9, 2018 at 9:15 PM, <James.White2@...> wrote:

I am not sure we know what version number to give Delhi yet.  I’d like to think it might actually be 1.0, but too soon to label it at this time. 

Is it important to tag the branch now versus when we cut a release?  I don’t recall having to tag at the start of a release before.

 

Is there a reason we are tagging at the start of a release versus at the end?

 

From: Jeremy Phelps [mailto:jphelps@linuxfoundation.org]
Sent: Monday, July 09, 2018 4:22 PM
To: Conn, Trevor
Cc: EdgeX-TSC-DevOps@lists.edgexfoundry.org; White2, James
Subject: Re: [Edgex-tsc-devops] Delhi release version

 

If we have the version for Delhi in the master branch already then we don't have that work to do after the cut.  The only work will be updating master again to the next release version.

 

On Mon, Jul 9, 2018 at 4:16 PM, <Trevor.Conn@...> wrote:

Hi Jeremy -- When you say "master" tag will hurt us, how do you mean? Wouldn't we just make a change to the desired version in the Delhi branch after the cut?

 

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: Monday, July 9, 2018 4:09 PM
To: edgex-tsc-devops@lists.edgexfoundry.org; White2, James; Conn, Trevor
Subject: [Edgex-tsc-devops] Delhi release version

 

Hi I'd like to bump the version on master branch for the Delhi release.  I talked with Trevor a bit about just calling it "master" but that will hurt us come time to cut the branch.

Are we shooting for 0.7.0?

Jeremy

 

 


Re: Delhi release version

James.White2@...
 

Ah – in that case… bump away.

 

From: Jeremy Phelps [mailto:jphelps@...]
Sent: Monday, July 09, 2018 9:23 PM
To: White2, James
Cc: Conn, Trevor; EdgeX-TSC-DevOps@...
Subject: Re: [Edgex-tsc-devops] Delhi release version

 

Building the artifacts with specified versions is different from git tagging.  The reason we want to bump the version on master before the release is for the daily staging jobs mostly.  We will be pointing blackbox tests at these, and to avoid confusion they should be different than our barcelona versions since they are already released.  Daily builds will of course overwrite but it's easier to reason about if we do bump.

 

 

On Mon, Jul 9, 2018 at 9:15 PM, <James.White2@...> wrote:

I am not sure we know what version number to give Delhi yet.  I’d like to think it might actually be 1.0, but too soon to label it at this time. 

Is it important to tag the branch now versus when we cut a release?  I don’t recall having to tag at the start of a release before.

 

Is there a reason we are tagging at the start of a release versus at the end?

 

From: Jeremy Phelps [mailto:jphelps@...]
Sent: Monday, July 09, 2018 4:22 PM
To: Conn, Trevor
Cc: EdgeX-TSC-DevOps@...; White2, James
Subject: Re: [Edgex-tsc-devops] Delhi release version

 

If we have the version for Delhi in the master branch already then we don't have that work to do after the cut.  The only work will be updating master again to the next release version.

 

On Mon, Jul 9, 2018 at 4:16 PM, <Trevor.Conn@...> wrote:

Hi Jeremy -- When you say "master" tag will hurt us, how do you mean? Wouldn't we just make a change to the desired version in the Delhi branch after the cut?

 

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: Monday, July 9, 2018 4:09 PM
To: edgex-tsc-devops@...; White2, James; Conn, Trevor
Subject: [Edgex-tsc-devops] Delhi release version

 

Hi I'd like to bump the version on master branch for the Delhi release.  I talked with Trevor a bit about just calling it "master" but that will hurt us come time to cut the branch.

Are we shooting for 0.7.0?

Jeremy

 

 

Re: Delhi release version

Jeremy Phelps
 

Building the artifacts with specified versions is different from git tagging.  The reason we want to bump the version on master before the release is for the daily staging jobs mostly.  We will be pointing blackbox tests at these, and to avoid confusion they should be different than our barcelona versions since they are already released.  Daily builds will of course overwrite but it's easier to reason about if we do bump.


On Mon, Jul 9, 2018 at 9:15 PM, <James.White2@...> wrote:

I am not sure we know what version number to give Delhi yet.  I’d like to think it might actually be 1.0, but too soon to label it at this time. 

Is it important to tag the branch now versus when we cut a release?  I don’t recall having to tag at the start of a release before.

 

Is there a reason we are tagging at the start of a release versus at the end?

 

From: Jeremy Phelps [mailto:jphelps@linuxfoundation.org]
Sent: Monday, July 09, 2018 4:22 PM
To: Conn, Trevor
Cc: EdgeX-TSC-DevOps@lists.edgexfoundry.org; White2, James
Subject: Re: [Edgex-tsc-devops] Delhi release version

 

If we have the version for Delhi in the master branch already then we don't have that work to do after the cut.  The only work will be updating master again to the next release version.

 

On Mon, Jul 9, 2018 at 4:16 PM, <Trevor.Conn@...> wrote:

Hi Jeremy -- When you say "master" tag will hurt us, how do you mean? Wouldn't we just make a change to the desired version in the Delhi branch after the cut?

 

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: Monday, July 9, 2018 4:09 PM
To: edgex-tsc-devops@lists.edgexfoundry.org; White2, James; Conn, Trevor
Subject: [Edgex-tsc-devops] Delhi release version

 

Hi I'd like to bump the version on master branch for the Delhi release.  I talked with Trevor a bit about just calling it "master" but that will hurt us come time to cut the branch.

Are we shooting for 0.7.0?

Jeremy

 


Re: Delhi release version

James.White2@...
 

I am not sure we know what version number to give Delhi yet.  I’d like to think it might actually be 1.0, but too soon to label it at this time. 

Is it important to tag the branch now versus when we cut a release?  I don’t recall having to tag at the start of a release before.

 

Is there a reason we are tagging at the start of a release versus at the end?

 

From: Jeremy Phelps [mailto:jphelps@...]
Sent: Monday, July 09, 2018 4:22 PM
To: Conn, Trevor
Cc: EdgeX-TSC-DevOps@...; White2, James
Subject: Re: [Edgex-tsc-devops] Delhi release version

 

If we have the version for Delhi in the master branch already then we don't have that work to do after the cut.  The only work will be updating master again to the next release version.

 

On Mon, Jul 9, 2018 at 4:16 PM, <Trevor.Conn@...> wrote:

Hi Jeremy -- When you say "master" tag will hurt us, how do you mean? Wouldn't we just make a change to the desired version in the Delhi branch after the cut?

 

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: Monday, July 9, 2018 4:09 PM
To: edgex-tsc-devops@...; White2, James; Conn, Trevor
Subject: [Edgex-tsc-devops] Delhi release version

 

Hi I'd like to bump the version on master branch for the Delhi release.  I talked with Trevor a bit about just calling it "master" but that will hurt us come time to cut the branch.

Are we shooting for 0.7.0?

Jeremy

 

Re: Delhi release version

Jeremy Phelps
 

If we have the version for Delhi in the master branch already then we don't have that work to do after the cut.  The only work will be updating master again to the next release version.

On Mon, Jul 9, 2018 at 4:16 PM, <Trevor.Conn@...> wrote:

Hi Jeremy -- When you say "master" tag will hurt us, how do you mean? Wouldn't we just make a change to the desired version in the Delhi branch after the cut?


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: Monday, July 9, 2018 4:09 PM
To: edgex-tsc-devops@lists.edgexfoundry.org; White2, James; Conn, Trevor
Subject: [Edgex-tsc-devops] Delhi release version
 
Hi I'd like to bump the version on master branch for the Delhi release.  I talked with Trevor a bit about just calling it "master" but that will hurt us come time to cut the branch.
Are we shooting for 0.7.0?
Jeremy

Re: Delhi release version

Trevor.Conn@...
 

Hi Jeremy -- When you say "master" tag will hurt us, how do you mean? Wouldn't we just make a change to the desired version in the Delhi branch after the cut?


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: Monday, July 9, 2018 4:09 PM
To: edgex-tsc-devops@...; White2, James; Conn, Trevor
Subject: [Edgex-tsc-devops] Delhi release version
 
Hi I'd like to bump the version on master branch for the Delhi release.  I talked with Trevor a bit about just calling it "master" but that will hurt us come time to cut the branch.
Are we shooting for 0.7.0?
Jeremy

Delhi release version

Jeremy Phelps
 

Hi I'd like to bump the version on master branch for the Delhi release.  I talked with Trevor a bit about just calling it "master" but that will hurt us come time to cut the branch.
Are we shooting for 0.7.0?
Jeremy

Blackbox tests

Jeremy Phelps
 

Hi All,
Blackbox tests are running and passing now after some environment fixups (Thanks Trevor for helping troubleshoot)


Andy and team,
Is is possible to get the IOTech contributions in tomorrow so that I can branch cut for california and get it running against those repos as well?

Jeremy

California branch cutting

Jeremy Phelps
 

Hello all,
I've cut the california branch for the following repositories:
"""
device-virtual
device-modbus
device-controller
device-sdk
device-snmp
device-fischertechnik
device-scheduling
device-bacnet
device-mqtt
device-domain
device-sdk-tools
device-bluetooth
core-config-seed-go
core-config-watcher
core-test
support-notifications
support-rulesengine
support-scheduler
edgex-go
export-domain
export-test
docker-edgex-mongo
docker-edgex-volume
"""
This means that no new functionality should go into this branch, at this point only bug fixes and test enhancements.
If there is something committed in a california branch that also needs to make it into master you should cherry pick that commit into a branch off of master locally and then PR to master.
Jeremy

Re: Gofmt git commit hook

Jeremy Phelps
 

Yeah we will explore this further for sure.  I did confirm that we will not be able to do git hooks on GitHubs servers; it's an obvious security concern for them.  With some work we can make something with webhooks though.
Jeremy

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

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@lists.edgexfoundry.org [mailto:EdgeX-TSC-DevOps@lists.edgexfoundry.org] On Behalf Of Jeremy Phelps
Sent: Friday, June 15, 2018 1:10 PM
To: Conn, Trevor
Cc: EdgeX-TSC-DevOps@lists.edgexfoundry.org; EdgeX-GoLang@lists.edgexfoundry.org
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