src-d / ci Goto Github PK

It seems to be a general recommendation:

Add each phony target as a prerequisite of .PHONY immediately before the target declaration, rather than listing all the phony targets in a single place.

sources:
http://style-guides.readthedocs.io/en/latest/makefile.html
http://clarkgrubb.com/makefile-style-guide#phony-targets

We are using Glide for some projects already, and we're likely to start using it in more.

It would be nice if the presence of glide.lock was enough to run glide and so on. Otherwise, defining a variable would also work.

E.g. hardcoded SHELL to /bin/bash and other things I have not checked yet.

Minimal requirement to consider this fixed: no errors in bblfsh/client-go.

Recipe for documentation tool in Go.

This needs to output api output under /api/go under the project folder.

Generate an index with the following info taken from .bbldc:

• Description
• License (SPDX code
• Issues link
• Project link

All of these taken from the file mentioned above.

Recipe for documentation tool in c / c++.

This needs to output api output under /api/c{,pp} under the project folder.

I'm trying to set up src-d/github-reminder and I'm having many issues:

• how do I obtain a new code coverage token?
• how do I specify the github token?
• how do I specify the name of the docker image to produce?

@mcuadros

make test-coverage never errors, even if the tests failed to build. Expected behavior: in case of any error, abort make and set the exit code, as all the normal build targets do.

This is especially funny when you realize that the test suite never actually ran after a few weeks.

Get a basic theme with out branding for generating the documentation of Python projects.

As the readme says, master is deprecated and the active branch is v1.
Many of us have made PRs against master by mistake, this would make it easy to avoid it. Also coming to the repository will automatically show the docs for the branch we actually use, avoiding confusion.

https://help.github.com/en/articles/setting-the-default-branch

Given the fields tutorials and usages generate two gitbooks under a given baseurl

This is just a reminder that, once we drop support for Go <1.10, we can simplify the test-coverage rule to do a single go test call for all packages.

See golang/go#6909

Since we migrated to go dep + checked in vendor directory on applications, we don't need glide support anymore.

There is a few things that are pending and may be improved in a v2 version. It would make sense to start thinking about it once Go 1.12 is out, specially if we consider to adopt Go modules and phase out go dep.

This would be my wishlist, it's just something to get started:

• Add support for Go modules, remove go dep stuff. This is still something that needs discussion, since we'll still keep using go dep in the short term.
• Enable windows builds by default. Make it explicit when disabling them instead.
• Specify PKG_PLATFORMS instead of PKG_OS and PKG_ARCH, so we have finer-grained control over GOOS/GOARCH pairs that are built.
• Drop support for older Go versions (e.g. Go 1.11 if we adopt modules).
• Simplify test-coverage by adopting the new support for coverage on multiple packages (this depends on dropping support for Go <=1.9) #64
• GitHub Actions support

Get a basic theme with out branding for generating the documentation of C / C++ projects.

Feature request: make packages creates tar.gz files for all architectures, but for windows users it would be more convenient to have zip files.

As an example when running make build in engine on OSX, the build/bin/srcd binary doesn't work as it corresponds to the binary for linux.

I'm wondering whether https://github.com/src-d/ci/blob/v1/Makefile.main#L28 and https://github.com/src-d/ci/blob/v1/Makefile.main#L29 should actually be "{{.Client.Os}}" and "{{.Client.Os}}" respectively.

See golang/go#31002, src-d/sourced-ce#154

Example output for sourced-ce:

$ make clean 
rm -rf build build/bin 
go clean .
can't load package: package github.com/src-d/sourced-ce: unknown import path "github.com/src-d/sourced-ce": cannot find module providing package github.com/src-d/sourced-ce
/home/cmartin/code/src-d/sourced-ce/.ci/Makefile.main:233: recipe for target 'clean' failed
make: *** [clean] Error 1

It seems that ci/Makefile.main::docker-push rule does not update the :latest tag when a new tag is pushed.

Binary name ($(BIN)) should have .exe appended on Windows.

Recipe for documentation tool in Java.

This needs to output api output under /api/java under the project folder.

Since src-d/gitbase-web#15 (See PR desc) integration tests are not running.
Thanks to src-d/gitbase-web#33 they could be run using docker compose.

Recipe for documentation tool in Scala.

This needs to output api output under /api/scala under the project folder.

Recipe for documentation tool in Python.

This needs to output api output under /api/python under the project folder.

Get a basic theme with out branding for generating the documentation of Java projects.

Get a basic theme with out branding for generating the documentation of Scala projects.

Tool that given a project, generates documentation with our branded theme for each language defined in the file .bbldc under the root folder of the given path.

This should be configurable to receive a baseurl. Each language will live under baseurl/api/:lang.

We need to move our private Makefile for CI after removing private fields (usernames, passwords, etc.)

Get a basic theme with out branding for generating the documentation of Go projects.

As a developer of a project that uses this project, I want to know how to clean my working directory after a successul build.

Currently, make packages can be used to build the project. It creates a build directory and bin directory. The make clean command only deletes the build directory, but not the bin.

We must also document if make clean is the proper invocation for this.

The README from this project starts with this sentence:

This project contains the common CI configuration for all source{d} Go projects...

And this is true. But we have been moving other functionality recently from other projects to this one, for instance, now that we use glide in some projects, a makefile is needed, and we have been adding targets here for building and testing outside of travis.

It looks as if we were broadening the focus of this project to a more general approach to building and testing go projects.

Is this so? Is there a firm commitment to this trend?, Can we explain that in the readme and also document the expected ways a developer should interact with this new functionality?

README.md has two broken links to examples/Makefile.main and examples/.travis.yml

As a developer of a project that uses this repo I would like to know how to compile and tests my projects.

I believe compiling is achieved by running make packages and the binary will be at bin/<name-of-project>.

I believe testing should be done by the project own makefile.

Executing go get to install go dep creates problems when there's a lock file generation changes. For example:

https://travis-ci.org/src-d/borges/jobs/402777244#L907

Downloading go dep should be done in Makefile and use the latest release instead of master branch.

The examples folder will contain folders with the name of the example and a few files:

For each file, convert it to a representation we can use to show them (either markdown or directly html).

As a developer of borges I find confusing that make packages does not leave a vendor directory in my project but make test does.

It looks like some high-level, user-oriented make targets, clean things while others don't.

Maybe we can document why this is happening or just make all high-level targets behave the same way.

PML team start to use go features of CI.

But one for a style check is missing. Now we use this code to run it:

check-style:
	golint -set_exit_status ./...
	[[ -z $$(gofmt -s -d .) ]] && [[ -z $$(goimports -d . ) ]] || exit 1 \
		# Run `goimports -w . && gofmt -s -w .` to fix style errors
	go vet

I propose to include this code to the main CI file because it is general for any Go project.

@smola WDYT?