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

Run specs on CircleCi with shared configuration #143

Merged
merged 5 commits into from
Jun 12, 2019
Merged

Conversation

kennyadsl
Copy link
Member

@kennyadsl kennyadsl commented Feb 15, 2019

A new way to run specs on extensions

The problem

Everytime a new Solidus version is released or goes EOL we need to refresh the CI configuration of all the extensions adding or removing a version. 😢
This is not maintainable with the current core team, and even if we had more development work this is not worth the time, everyone can find better things to do than repeat the same commit on 30 extensions.

Requirements

Before presenting the solution I'd like to list our requirements: what we need in order to be able to move from TravisCI to another solution?

  • Centralized configuration: we need an external container for the environment configuration where specs run, at least for the supported solidus versions, which is the thing that changes more often
  • Ability to change the centralized configuration and have this change reflected into all the extensions that are using it without the need to make a commit for that
  • Setup a recurring scheduled build against master: this ensures that if we change something in core that brakes extensions we are notified before releasing Solidus.
  • Being able to access build status data via API to populate extensions.solidus.io, which is currently done in this repo: https://github.com/solidusio/extensions.solidus.io

Proposed Solution

Using CircleCI Orbs we can define a shared configuration that every extension will use at its latest version.

Lately, we experimented a lot with CircleCI Orbs at Nebulab. Our goal there is having a shared CircleCI configuration that we can use on several projects since we use the same tasks. In the past it has been a pain when we needed to update the CircleCI configuration and spread the change on every project that we manage. Working on that I thought that we could use this same approach for this extensions problem and I started experimenting with this PR.

This is the orb used in this PR. This orb is packed and released at every commit on the master branch of this solidusio/circleci-orbs-extensions repository.

It basically defines shared tasks that our extensions will use.

With @volatile

orbs:
  solidusio_extensions: solidusio/extensions@volatile

we ensure that the extension will always build against the last orb code, which will contain the list of currently supported Solidus versions. The run-tests command is the only file that we need to change on the orb.

The orb also defines two executors (for mysql and postgres), which allow us to configure the environment where we want tests to run.

The configuration of each extension will only have the responsibility to call these shared commands and executors from the orb.

Extensions Matrix website

I've also created the integration with CircleCI to generate the matrix. Here's the Draft PR and the resulting preview.

We can either use it and dismiss the old Travis matrix, or move to a simpler solution (like a simple badge in solidus.io/extensions).

What do you think?

Your feedback is important here. We are interested in help improving this solution if any of you have experience with CircleCI and Orbs and also if you have any feedback about if it would be acceptable to dismiss the extensions matrix website, in favor of a simpler solution.

Let me know!


TODO:

  • create the CircleCI orb configuration so that we can change supported versions in a single point
  • always use latest version of the orb so we can easily propagate the change without any commit
  • scheduled weekly builds on all extensions
  • update extensions matrix (move to solidus.io/extensions with a badge?)

@kennyadsl kennyadsl force-pushed the kennyadsl/circleci branch from d223008 to 1667a1c Compare June 4, 2019 14:53
kennyadsl added 3 commits June 4, 2019 16:58
so we can update the orb and the change will propagate to all
the extensions automatically
@kennyadsl kennyadsl changed the title [WIP] Test CircleCI config to run specs Run specs with CircleCi with shared configuration Jun 4, 2019
We already have this feature in travis and we should keep it since
we need an alert if something merged in core is breaking extensions,
even if they remain untouched.
@kennyadsl kennyadsl force-pushed the kennyadsl/circleci branch from 41c664a to f695f43 Compare June 5, 2019 15:23
@kennyadsl kennyadsl changed the title Run specs with CircleCi with shared configuration Run specs on CircleCi with shared configuration Jun 12, 2019
Copy link
Member

@tvdeyen tvdeyen left a comment

Choose a reason for hiding this comment

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

Wow! This is awesome. 👏

Should we remove the Travis build from mandatory checks for this repo then? The CircleCI builds pass, but the travis ones fail for obvious reasons.

Copy link

@ericsaupe ericsaupe left a comment

Choose a reason for hiding this comment

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

Awesome work!

@kennyadsl
Copy link
Member Author

@tvdeyen I think they can also live together for a while, failures are related to Solidus v2.8, which needed some backport fixes, done with solidusio/solidus#3194. I've restarted the failing builds, now we should have both green.

My only concern is with the extension matrix website, but I'm working on supporting both systems in there and gradually switch.

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.

3 participants