Skip to content
New issue

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

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

Already on GitHub? # to your account

[WIP] Create CircleCI config #484

Merged
merged 3 commits into from
Jun 24, 2019
Merged

[WIP] Create CircleCI config #484

merged 3 commits into from
Jun 24, 2019

Conversation

elithrar
Copy link
Contributor

Validate CircleCI.

@elithrar elithrar added the build label Jun 16, 2019
@elithrar elithrar self-assigned this Jun 16, 2019
@elithrar
Copy link
Contributor Author

PS: Don't merge, this is a WIP / demo / validating whether it's worth migrating to.

@elithrar elithrar changed the title [ci] Create CircleCI config [WIP] Create CircleCI config Jun 16, 2019
@fharding1
Copy link
Contributor

fharding1 commented Jun 16, 2019

My $0.02: I've used CircleCI for a few projects and have had nothing but good experiences. Simple configuration, decent build time, and used widely enough for most people to be somewhat familiar with it. Then again, I could say most of those things for Travis :)

👍 moving to CircleCI

@elithrar
Copy link
Contributor Author

Istio, et. al using it also inspire a bit of confidence. I'm going to leave this open for the time being - I also need to think about moving all Gorilla projects over (not just one) as part of this.

@elithrar
Copy link
Contributor Author

Some initial explorations around DRY'ing the config, at the expense of workflow/status visibility - which isn't a worthwhile trade-off, IMO - https://gist.github.com/elithrar/4fa799c66b2c9932ac33f450f0787a58

The thing I'm mostly trying to solve for is versioning - I want it to be easy to run multiple versions (since we do so for backwards-compat!) and minimize human error when it comes to writing the CI config itself.

@elithrar
Copy link
Contributor Author

elithrar commented Jun 24, 2019

Going to merge and let co-exist with TravisCI for a while. Next steps would be to:

  • Replace TravisCI entirely
  • Script creation of a .circleci/config.yml for all gorilla/* repos based on their existing Travis CI config.

I'm also using this for another OSS project I'm about to release - to both test the library & build a container image - and the flexibility definitely pays off more there.

@elithrar elithrar merged commit 212aa90 into master Jun 24, 2019
@elithrar elithrar deleted the elithrar/ci/circleci-1 branch June 24, 2019 16:05
@kisielk
Copy link
Contributor

kisielk commented Jun 24, 2019

Would also be nice if the CircleCI script could somehow pick up new versions of Go into the build matrix. I'm not sure if that's possible or not, but that was always a maintenance headache with the travis config.

@elithrar
Copy link
Contributor Author

@kisielk - no, but that’d be great. A @circleci bot that can PR your config.yml with new versions would be nice though...

Part of the reason for wanting to write a script + template is so that we can code-gen creation of configs across repos and avoid skew. Now, to find the time for that...

@elithrar
Copy link
Contributor Author

For posterity: the script used to generate config.yml for every repo - https://gist.github.com/elithrar/3bf2e3bd60292e71d3b735cdab06cc78

PRs were still manual; those are next to automate - likely by traversing the repos under $GOPATH/src/github.com/gorilla and running a few git commands (branch, add, commit, push).

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants