Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build Reasons and Changes diff #556

Merged
merged 3 commits into from
Dec 14, 2020
Merged

Conversation

sukhil-suresh
Copy link
Contributor

@sukhil-suresh sukhil-suresh commented Nov 23, 2020

The PR updates the prepare and rebase stages of the Build process to display the Build Reason and corresponding Change diff.

  • Sample output captured in this comment
  • Build Reason sort index is currently set to "TRIGGER,COMMIT,CONFIG,BUILDPACK,STACK"
  • Username was dropped from the TRIGGER message (at least for the first iteration) after discussion

@sukhil-suresh sukhil-suresh changed the title Wip reason message diff Reason message diff Nov 23, 2020
@sukhil-suresh sukhil-suresh changed the title Reason message diff Build Reasons and Changes diff Nov 23, 2020
@djoyahoy
Copy link
Contributor

@sukhil-suresh is there an environment variable limit that would prevent use from storing all changes in the BUILD_CHANGES env var?

@sukhil-suresh
Copy link
Contributor Author

@sukhil-suresh is there an environment variable limit that would prevent use from storing all changes in the BUILD_CHANGES env var?

Yes, there is a size limit on linux per environment variable and I believe for the combined block of env variables. I don't have a definitive number on hand; but based on google search it seems to be a 128KiB limit. It is also configurable.

The alternative considered was the Downward API Volume files but opted not to go down that path based on some very rough math of the changes value maxing out between 1500..2000 chars (at the moment)

But yes, still open to changing approach of passing the Changes value around

@djoyahoy
Copy link
Contributor

@sukhil-suresh is there an environment variable limit that would prevent use from storing all changes in the BUILD_CHANGES env var?

Yes, there is a size limit on linux per environment variable and I believe for the combined block of env variables. I don't have a definitive number on hand; but based on google search it seems to be a 128KiB limit. It is also configurable.

The alternative considered was the Downward API Volume files but opted not to go down that path based on some very rough math of the changes value maxing out between 1500..2000 chars (at the moment)

But yes, still open to changing approach of passing the Changes value around

That makes sense, thanks!

@sukhil-suresh
Copy link
Contributor Author

sukhil-suresh commented Nov 23, 2020

Captured Build reason(s) and Change diff for the different Build Reasons: CONFIG, TRIGGER, COMMIT, STACK, and BUILDPACK
The last one is for a combination of TRIGGER and BUILDPACK

CONFIG

$ kp image create test-image --tag sukhilsuresh/test-image --git https://github.com/paketo-buildpacks/samples --git-revision main --sub-path go/mod
Creating Image...
Image "test-image" created

$ kp build logs test-image
===> PREPARE
Build reason(s): CONFIG
CONFIG change:
	resources:
	  Limits: null
	  Requests: null
	source:
	  Blob: null
	-   Git: null
	+   Git:
	+     revision: 948b2eff6a21580a44a0f4d8c609a2af45359d41
	+     url: https://github.com/paketo-buildpacks/samples
	  Registry: null
	-   SubPath: ""
	+   SubPath: go/mod
Loading secret for "gcr.io" from secret "gcr" at location "/var/build-secrets/gcr"
....

TRIGGER

$ kp image trigger test-image
Triggered build for Image "test-image"

$ kp build logs test-image
===> PREPARE
Build reason(s): TRIGGER
TRIGGER change:
	A new build was manually triggered on Mon, 23 Nov 2020 16:16:26 -0500
Loading secret for "gcr.io" from secret "gcr" at location "/var/build-secrets/gcr"
...

COMMIT

$ kp build logs test-image
===> PREPARE
Build reason(s): COMMIT
COMMIT change:
	- 948b2eff6a21580a44a0f4d8c609a2af45359d41
	+ ec6f737864fa12374d5e8ee1db09058ab4e21ebf
Loading secret for "gcr.io" from secret "gcr" at location "/var/build-secrets/gcr"
...

STACK

$ kp clusterstack update full -b registry.pivotal.io/tbs-dependencies/build-full@sha256:e60c6717b2b6e8458f8f782c13fd2f60ef9e2f1f378fbb219be5da13538114aa -r registry.pivotal.io/tbs-dependencies/run-full@sha256:42841631725942db48b7ba8b788b97374a2ada34c84ee02ca5e02ef3d4b0dfca
Updating ClusterStack...
Uploading to 'gcr.io/cf-build-service-dev-219913/ssuresh/install'...
	Uploading 'gcr.io/cf-build-service-dev-219913/ssuresh/install/build@sha256:e60c6717b2b6e8458f8f782c13fd2f60ef9e2f1f378fbb219be5da13538114aa'
	Uploading 'gcr.io/cf-build-service-dev-219913/ssuresh/install/run@sha256:42841631725942db48b7ba8b788b97374a2ada34c84ee02ca5e02ef3d4b0dfca'


$ kp build logs test-image
===> REBASE
Build reason(s): STACK
STACK change:
	- RunImage: sha256:87302783be0a0cab9fde5b68c9954b7e9150ca0d514ba542e9810c3c6f2984ad
	+ RunImage: sha256:42841631725942db48b7ba8b788b97374a2ada34c84ee02ca5e02ef3d4b0dfca
Loading secret for "gcr.io" from secret "gcr" at location "/var/build-secrets/gcr"
...

BUILDPACK

$ kp clusterstore status default
Status:    Ready

BUILDPACKAGE ID                       VERSION    HOMEPAGE
paketo-buildpacks/procfile            2.0.2      https://github.com/paketo-buildpacks/procfile
tanzu-buildpacks/dotnet-core          0.0.6
tanzu-buildpacks/go                   1.0.5
tanzu-buildpacks/httpd                0.0.39
tanzu-buildpacks/java                 3.8.0      https://github.com/pivotal-cf/tanzu-java
tanzu-buildpacks/java-native-image    3.6.0      https://github.com/pivotal-cf/tanzu-java-native-image
tanzu-buildpacks/nginx                0.0.46
tanzu-buildpacks/nodejs               1.2.2
tanzu-buildpacks/php                  0.0.5

$ kp clusterstore add default -b registry.pivotal.io/tanzu-go-buildpack/go@sha256:ed99e73df43380c86c983e09d97151caf1952e8f423053a6e0a15de526515f4c
Adding to ClusterStore...
	Uploading 'gcr.io/cf-build-service-dev-219913/ssuresh/install/tanzu-buildpacks_go@sha256:ed99e73df43380c86c983e09d97151caf1952e8f423053a6e0a15de526515f4c'
	Added Buildpackage
ClusterStore "default" updated

$ kp clusterstore status default
Status:    Ready

BUILDPACKAGE ID                       VERSION    HOMEPAGE
paketo-buildpacks/procfile            2.0.2      https://github.com/paketo-buildpacks/procfile
tanzu-buildpacks/dotnet-core          0.0.6
tanzu-buildpacks/go                   1.0.5
tanzu-buildpacks/go                   1.0.7
tanzu-buildpacks/httpd                0.0.39
tanzu-buildpacks/java                 3.8.0      https://github.com/pivotal-cf/tanzu-java
tanzu-buildpacks/java-native-image    3.6.0      https://github.com/pivotal-cf/tanzu-java-native-image
tanzu-buildpacks/nginx                0.0.46
tanzu-buildpacks/nodejs               1.2.2
tanzu-buildpacks/php                  0.0.5

$ kp build logs test-image
===> PREPARE
Build reason(s): BUILDPACK
BUILDPACK change:
	- tanzu-buildpacks/go-build	0.0.22
	- tanzu-buildpacks/go-dist	0.1.0
	- tanzu-buildpacks/go-mod-vendor	0.0.24
	+ tanzu-buildpacks/go-build	0.0.23
	+ tanzu-buildpacks/go-dist	0.1.2
	+ tanzu-buildpacks/go-mod-vendor	0.0.25
Loading secret for "gcr.io" from secret "gcr" at location "/var/build-secrets/gcr"
...

Combination of TRIGER and BUILDPACK

$ kp build logs test-image
===> PREPARE
Build reason(s): TRIGGER,BUILDPACK
TRIGGER change:
	A new build was manually triggered on Mon, 23 Nov 2020 17:14:53 -0500
BUILDPACK change:
	- tanzu-buildpacks/go-build	0.0.23
	- tanzu-buildpacks/go-dist	0.1.2
	- tanzu-buildpacks/go-mod-vendor	0.0.25
	+ tanzu-buildpacks/go-build	0.0.22
	+ tanzu-buildpacks/go-dist	0.1.0
	+ tanzu-buildpacks/go-mod-vendor	0.0.24
Loading secret for "gcr.io" from secret "gcr" at location "/var/build-secrets/gcr"
...

@sampeinado
Copy link
Contributor

This looks AWESOME !!

A few comments:

  • for trigger, it says "TRIGGER change:" which doesn't really make sense. Would it be possible to say just "TRIGGER"?
  • for the CONFIG change, how does the system decide how many additional lines to print other than the diffed lines?

@sukhil-suresh
Copy link
Contributor Author

  • for trigger, it says "TRIGGER change:" which doesn't really make sense. Would it be possible to say just "TRIGGER"?

@sampeinado Assuming you were referring to a format similar to the one below? Yes, can make that change

===> PREPARE
Build reason(s): TRIGGER,BUILDPACK
TRIGGER: A new build was manually triggered on Mon, 23 Nov 2020 16:16:26 -0500
BUILDPACK change:
	- tanzu-buildpacks/go-build	0.0.23
	- tanzu-buildpacks/go-dist	0.1.2
	- tanzu-buildpacks/go-mod-vendor	0.0.25
	+ tanzu-buildpacks/go-build	0.0.22
	+ tanzu-buildpacks/go-dist	0.1.0
	+ tanzu-buildpacks/go-mod-vendor	0.0.24

@sampeinado
Copy link
Contributor

yes exactly! I think that makes more sense

@sukhil-suresh
Copy link
Contributor Author

sukhil-suresh commented Nov 24, 2020

@sampeinado

  • for the CONFIG change, how does the system decide how many additional lines to print other than the diffed lines?

For context...

$ kp build logs test-image
===> PREPARE
Build reason(s): CONFIG
CONFIG change:
	resources:
	  Limits: null
	  Requests: null
	source:
	  Blob: null
	-   Git: null
	+   Git:
	+     revision: 948b2eff6a21580a44a0f4d8c609a2af45359d41
	+     url: https://github.com/paketo-buildpacks/samples
	  Registry: null
	-   SubPath: ""
	+   SubPath: go/mod
Loading secret for "gcr.io" from secret "gcr" at location "/var/build-secrets/gcr"
...

I am assuming you are referring to the resources: being listed? I do see the oddity of it since it provides no additional context. I am not sure why that gets listed (in spite of the effort to suppress). Will look more into it.

About how the diff is generated? The Config objects are serialized to string and then compared. Test case that covers the CONFIG scenario.

sukhil-suresh added a commit that referenced this pull request Nov 24, 2020
Address change request on PR
#556 (comment)
sukhil-suresh added a commit that referenced this pull request Nov 24, 2020
Address change request on PR
#556 (comment)

Co-authored-by: Elenore Bastian <ebastian@vmware.com>
sukhil-suresh added a commit that referenced this pull request Nov 25, 2020
Avoid showing irrelevant fields during diff
Ref: #556 (comment)

Co-authored-by: Elenore Bastian <ebastian@vmware.com>
@sukhil-suresh
Copy link
Contributor Author

sukhil-suresh commented Nov 25, 2020

A few comments:

  • for trigger, it says "TRIGGER change:" which doesn't really make sense. Would it be possible to say just "TRIGGER"?
  • for the CONFIG change, how does the system decide how many additional lines to print other than the diffed lines?

Updated CONFIG, and TRIGGER change (based on @sampeinado comments)

CONFIG

$ kp image create test-image --tag sukhilsuresh/test-image --git https://github.com/paketo-buildpacks/samples --git-revision main --sub-path go/mod
Creating Image...
Image "test-image" created

$ kp build logs test-image
===> PREPARE
Build reason(s): CONFIG
CONFIG change:
	- source: {}
	+ source:
	+   git:
	+     revision: 948b2eff6a21580a44a0f4d8c609a2af45359d41
	+     url: https://github.com/paketo-buildpacks/samples
	+   subPath: go/mod
Loading secret for "gcr.io" from secret "gcr" at location "/var/build-secrets/gcr"
...

TRIGGER

$ kp image trigger test-image
Triggered build for Image "test-image"

$ kp build logs test-image
===> PREPARE
Build reason(s): TRIGGER
TRIGGER: A new build was manually triggered on Tue, 24 Nov 2020 21:12:39 -0500
Loading secret for "gcr.io" from secret "gcr" at location "/var/build-secrets/gcr"
...

sukhil-suresh added a commit that referenced this pull request Dec 9, 2020
- use only changes string
- changes string is now parsed into an array of GenericChange object
- changes on old/new fields are printed as is provided
- multiple change errors are bunched and reported for ChangeProcessor

Reason for the switch to a lightweight logger is captured in this issue
comment: #556 (comment)
sukhil-suresh added a commit that referenced this pull request Dec 9, 2020
- use only changes string
- changes string is now parsed into an array of GenericChange object
- changes on old/new fields are printed as is provided
- multiple change errors are bunched and reported for ChangeProcessor

Reason for the switch to a lightweight logger is captured in this issue
comment: #556 (comment)
sukhil-suresh added a commit that referenced this pull request Dec 9, 2020
- use only changes string
- changes string is now parsed into an array of GenericChange object
- changes on old/new fields are printed as is provided
- multiple change errors are bunched and reported for ChangeProcessor

Reason for the switch to a lightweight logger is captured in this issue
comment: #556 (comment)
sukhil-suresh added a commit that referenced this pull request Dec 10, 2020
- use only changes string
- changes string is now parsed into an array of GenericChange object
- changes on old/new fields are printed as is provided
- multiple change errors are bunched and reported for ChangeProcessor

Reason for the switch to a lightweight logger is captured in this issue
comment: #556 (comment)
sukhil-suresh added a commit that referenced this pull request Dec 10, 2020
- use only changes string
- changes string is now parsed into an array of GenericChange object
- changes on old/new fields are printed as is provided
- multiple change errors are bunched and reported for ChangeProcessor

Reason for the switch to a lightweight logger is captured in this issue
comment: #556 (comment)
Tyler Phelan and others added 3 commits December 14, 2020 14:42
Source: https://git.io/JklOZ https://git.io/JklOB

Co-authored-by: Sukhil Suresh <ssukhil@vmware.com>
Update the `prepare` and `rebase` stages of the Build process to
display the Build Reason and corresponding Change diff for a Build

Co-authored-by: Elenore Bastian <ebastian@vmware.com>
- use only changes string
- changes string is now parsed into an array of GenericChange object
- changes on old/new fields are printed as is provided
- multiple change errors are bunched and reported for ChangeProcessor

Reason for the switch to a lightweight logger is captured in this issue
comment: #556 (comment)

Co-authored-by: Sukhil Suresh <ssukhil@vmware.com>
@sukhil-suresh sukhil-suresh merged commit 7bbae2c into master Dec 14, 2020
@sukhil-suresh sukhil-suresh deleted the wip-reason-message-diff branch December 14, 2020 19:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add reason-message and reasons diff to build logs
6 participants