Skip to content

use the Makefile.common#3978

Merged
krasi-georgiev merged 5 commits intoprometheus:masterfrom
krasi-georgiev:makefile.common
Apr 19, 2018
Merged

use the Makefile.common#3978
krasi-georgiev merged 5 commits intoprometheus:masterfrom
krasi-georgiev:makefile.common

Conversation

@krasi-georgiev
Copy link
Contributor

@krasi-georgiev krasi-georgiev commented Mar 18, 2018

@krasi-georgiev krasi-georgiev force-pushed the makefile.common branch 4 times, most recently from 99c347c to 3a8a739 Compare March 18, 2018 19:03
@brian-brazil
Copy link
Contributor

This is a good start. I think that the common Makefile should live in either the promu or prometheus repos, not in common which is library code. Downloading it on the fly will be fragile, I'd prefer that it get updated via tooling+PRs.

@krasi-georgiev
Copy link
Contributor Author

the idea is to keep a local cached copy like I did in the prometheus PR , the -f flag means if the pull fails don't override the existing file and just run the cached copy.

What is your idea to keep it up to date?

@brian-brazil
Copy link
Contributor

We send a batch of PRs every time it changes. That way we know that each repo is always buildable.

@krasi-georgiev
Copy link
Contributor Author

a PR on every change of Makefile.common?
wasn't this how it was few years ago and didn't work well?
https://docs.google.com/document/d/1Ql-f_aThl-2eB5v3QdKV_zgBdetLLbdxxChpy-TnWSE

what about that -f flag do you see any problem with that?

@brian-brazil
Copy link
Contributor

wasn't this how it was few years ago and didn't work well?

Makefiles never went away, and each Makefile was still altered on an as-needed basis and things still drifted.

what about that -f flag do you see any problem with that?

Changing behaviour depending on whether we get a HTTP response is fragile.

@krasi-georgiev
Copy link
Contributor Author

krasi-georgiev commented Mar 19, 2018

your idea is to keep Makefile.common in lets say prometheus/prometheus and each time it needs a change to open a PR against each other prometheus repo ?

Changing behaviour depending on whether we get a HTTP response is fragile.
don't quite understand what you mean here.
my suggestion is to keep a local cached copy of the Makefile.common at all times.

@brian-brazil
Copy link
Contributor

Yes.

my suggestion is to keep a local cached copy of the Makefile.common at all times.

Only using it sometimes is fragile and will lead to confusion.

@krasi-georgiev
Copy link
Contributor Author

maybe adding make update to explicitly update the cached version.
but anyway what kind of confusion do you think it might lead to?

one problem I am trying to avoid is merging PR's by mistakes on repos different than the main source of the Makefile.common which might happen quite often if Makefile.common gets addopted by many repos.

@brian-brazil
Copy link
Contributor

but anyway what kind of confusion do you think it might lead to?

People on flaky internet connections get different behaviour, and there's now N potential makefiles that could be in use depending on when it last worked.

@krasi-georgiev
Copy link
Contributor Author

as per the prometheus devs objection I have removed the auto-update

https://groups.google.com/forum/#!topic/prometheus-developers/4734cvJHCn4

@brian-brazil
Copy link
Contributor

👍

@krasi-georgiev
Copy link
Contributor Author

krasi-georgiev commented Mar 28, 2018

@brian-brazil thanks
@SuperQ, @grobie do you see any problems with this or I can merge?

next I will open issues for the other golang repos to start using the common targets.

Copy link
Member

@grobie grobie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dislike making a fast internet connection a development requirement (by redownloading promu on every single make build execution).

I also don't like hiding the actually executed commands, as this means I first need to read the Makefile to understand how to build Prometheus without triggering the promu download.

Makefile.common Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

End the file with a newline.

Makefile.common Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not showing what is being executed and especially downloaded in a Makefile is something I consider an anti-pattern and has led to several questions and support overhead when these downloads hang/fail.

I don't understand why a line >> fetching promu is preferred over showing the user what we install directly (e.g. go get -u github.com/prometheus/promu). Not show the commands makes debugging very hard.

@brian-brazil
Copy link
Contributor

I dislike making a fast internet connection a development requirement (by redownloading promu on every single make build execution).

I'm not a fan either, but it's what the existing Makefile does so I don't think this is the PR to propose changing it.

@krasi-georgiev
Copy link
Contributor Author

I agree that we should show the commands that are running so updated and will merge on green.

the promu fetch will be left for another PR.

@grobie
Copy link
Member

grobie commented Mar 28, 2018

it's what the existing Makefile does so I don't think this is the PR to propose changing it.

I understood this PR to introduce the common Makefile which will be introduced in all projects, as it aims to resolve #3904. If this is not the final PR for that, feel free to merge.

@krasi-georgiev
Copy link
Contributor Author

krasi-georgiev commented Mar 28, 2018

@grobie any suggestions or a link to another makefile that handles the promu fetch better?

@krasi-georgiev
Copy link
Contributor Author

as of golang 1.9 the vendored dir is excluded so I updated it to just use ./... with any command.

@brian-brazil
Copy link
Contributor

client_golang still supports back to 1.7.x

@brian-brazil
Copy link
Contributor

Though on the other hand client_golang doesn't have any vendoring.

@krasi-georgiev
Copy link
Contributor Author

krasi-georgiev commented Mar 29, 2018

I thought of that , but client_golang doesn't have a Makefile , do we even need one there?

@brian-brazil
Copy link
Contributor

Most of it won't be useful, but the things like tests apply.

@krasi-georgiev
Copy link
Contributor Author

what it is the promise on the golang version for the client_golang?
At the moment it doesn't have a makefile and if you think that by the time we would need a makefile the minimum golang version would be 1.9 , than best to leave the common makefile as is.

Makefile.common Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The all target should abort incorrectly formatted code, instead of silently formatting it. Replace format with style.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should stay as-is as this is what a human will use. Maybe a separate CI target?

This is a matter for another PR in any case, we shouldn't be making changes here just refactoring.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All other targets abort the command and require the user to fix it, format is the only one behaving differently. Introducing another target is unnecessary and complicates all CI integrations which commonly just execute make.

This PR is explicitely labeled to introduce the new common Makefile for all projects, so either that needs to be changed or this is the PR where I have to request such changes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR is explicitely labeled to introduce the new common Makefile for all projects, so either that needs to be changed or this is the PR where I have to request such changes.

This is just a refactoring. Once it is in changes can be made before it is propagated out.

@SuperQ
Copy link
Member

SuperQ commented Apr 10, 2018

Sorry for being idle on this conversation.

I like the idea of having make update_common_makefile.

One idea, we could include this in our cicleci test pipeline.

@krasi-georgiev
Copy link
Contributor Author

One idea, we could include this in our cicleci test pipeline.

@SuperQ can you explain a bit more as I didn't quite understand the idea

Copy link
Member

@grobie grobie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving given @brian-brazil says "This is just a refactoring.".

@krasi-georgiev
Copy link
Contributor Author

would need to merge this one first to pass the tests.
#4073

@SuperQ
Copy link
Member

SuperQ commented Apr 10, 2018

@krasi-georgiev We run a number of tests automatically. We could add a test failure into the build setup to fail if the common makefile changes. This might be slightly annoying for unrelated updates, but it helps address @grobie's desire for offline development. (I agree with the desire for offline development)

@krasi-georgiev
Copy link
Contributor Author

@SuperQ the original PR allowed offline mode, by using a cached version when no internet connection.
The main concern was that a bad update of the Makefile.common would propagate in all projects that are using it causing many open PRs to fail.
If I understand your suggestion properly it will lead to the same problem, no ?

Copy link
Contributor

@brian-brazil brian-brazil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing things in a PR where you're mainly moving code around makes it hard to review, and increases the chances that a mistake/change will be missed. Keep this to moving things around, changes can be done in the next PR.

Makefile.common Outdated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is changed from the original, don't change semantics in a refactoring PR

Copy link
Contributor Author

@krasi-georgiev krasi-georgiev Apr 11, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

completely agree in general.
These changes are small enough and I hope we can make an exception.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the small changes in this PR are rewriting most of the file. It'd be easier to review if things were kept simpler. At least split it into sane commits.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I had them split logically, but I squashed few because of the DCO.

Now rebased with master and all tests look good.

Makefile.common Outdated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is changed from the original

Signed-off-by: Krasi Georgiev <krasi.root@gmail.com>
Signed-off-by: Krasi Georgiev <krasi.root@gmail.com>
Signed-off-by: Krasi Georgiev <krasi.root@gmail.com>
Copy link
Contributor

@brian-brazil brian-brazil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is still hard to review with mixing of refactoring and changes.

Makefile.common Outdated

unused: $(GOVENDOR)
@echo ">> running check for unused packages"
@$(GOVENDOR) list +unused | grep . && exit 1 || echo 'No unused packages'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has changed

Signed-off-by: Krasi Georgiev <krasi.root@gmail.com>
@krasi-georgiev
Copy link
Contributor Author

Reverted all mentioned changes.

@brian-brazil
Copy link
Contributor

👍

@krasi-georgiev
Copy link
Contributor Author

if no one else has anymore suggestions merging tomorrow.


style:
@echo ">> checking code style"
! $(GOFMT) -d $$(find . -path ./vendor -prune -o -name '*.go' -print) | grep '^'
Copy link
Contributor Author

@krasi-georgiev krasi-georgiev Apr 18, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes at the moment the output is quite busy , but I will open another PR to simply ./...

Makefile.common Outdated

check_license:
@echo ">> checking license header"
for file in $$(find . -type f -iname '*.go' ! -path './vendor/*') ; do \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The recipe doesn't fail when license headers are missing. I got it fixed as:

-       for file in $$(find . -type f -iname '*.go' ! -path './vendor/*') ; do \
-               awk 'NR<=3' $$file | grep -Eq "(Copyright|generated|GENERATED)" || echo "license header checking failed for:" $$file  ; \
-       done
+       @licRes=$$(for file in $$(find . -type f -iname '*.go' ! -path './vendor/*') ; do \
+               awk 'NR<=3' $$file | grep -Eq "(Copyright|generated|GENERATED)" || echo $$file; \
+       done); \
+       if [ -n "$${licRes}" ]; then \
+               echo "license header checking failed:"; echo "$${licRes}"; \
+               exit 1; \
+       fi

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep , thanks , updated.


style:
@echo ">> checking code style"
! $(GOFMT) -d $$(find . -path ./vendor -prune -o -name '*.go' -print) | grep '^'
Copy link
Contributor Author

@krasi-georgiev krasi-georgiev Apr 18, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes at the moment the output is quite busy , but I will open another PR to simply ./...

Signed-off-by: Krasi Georgiev <krasi.root@gmail.com>
@krasi-georgiev krasi-georgiev merged commit 3f2b2c5 into prometheus:master Apr 19, 2018
@krasi-georgiev krasi-georgiev deleted the makefile.common branch July 5, 2018 17:05
gouthamve pushed a commit to gouthamve/prometheus that referenced this pull request Aug 1, 2018
split common targets in a  Makefile.common to reuse it across projects

Signed-off-by: Krasi Georgiev <krasi.root@gmail.com>
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.

Reuse the same Makefile across projects

6 participants