Re: [Dev] GitLab CI

2015-07-10 Thread Peter Harpending
On Thu, Jul 09, 2015 at 10:40:39PM -0700, Aaron Wolf wrote:
 So, we've been chatting about Continuous Integration… I didn't know
 before about this: https://about.gitlab.com/gitlab-ci/ — fully FLO CI
 designed for GitLab… is there a chance we could use that?

From reading the page, it sounds like *every* instance of GitLab will
have that, it's just a matter of whether or not it is enabled.

Peter Harpending


pgpuRQYADhrrY.pgp
Description: PGP signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev


Re: [Dev] GitLab CI

2015-07-10 Thread Bryan Richter
On Thu, Jul 09, 2015 at 10:40:39PM -0700, Aaron Wolf wrote:
 So, we've been chatting about Continuous Integration… I didn't know
 before about this: https://about.gitlab.com/gitlab-ci/ — fully FLO CI
 designed for GitLab… is there a chance we could use that?

The free version seems to only work for projects on gitlab.com. I can
sign in, but since I have no projects on gitlab.com I can't do
anything.

This is analagous to having free* Travis CI on Github, which is also no
use to us.

Travis! -- needs Github
Gitlab CI! -- needs Gitlab

You see the pattern.

*IF* the person running git.gnu.io set up a local instance of Gitlab
CI, we could use that. Or they could set up any other CI system. Or we
could set one up ourselves.

If we're going to set up one ourselves, it makes sense to use bake,
contributing any necessary features back to the project as they arise.
I say that with no greater rationale than it is also written in
Haskell. Really, if *anyone* makes *any* CI available to our project,
that would be rad.

The hard requirements are:

1. Is triggered by HTTP POST requests.
2. For merge requests, it checks out master, merges the request
branch, runs tests, and reports results.
3. It logs each attempt somewhere accessible.

Ideally, the reporting would be *right in the merge request*, as it is
with Travis on Github. It's actually possible this could be done
without modifying Gitlab, if the CI system could write comments on the
MR's discussion.

* Only free as in beer, of course: Testing your open source project
  is 1% free. Seriously. Always.


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev


Re: [Dev] GitLab CI

2015-07-10 Thread Aaron Wolf

On 07/10/2015 08:11 AM, Bryan Richter wrote:
 On Thu, Jul 09, 2015 at 10:40:39PM -0700, Aaron Wolf wrote:
 So, we've been chatting about Continuous Integration… I didn't know
 before about this: https://about.gitlab.com/gitlab-ci/ — fully FLO CI
 designed for GitLab… is there a chance we could use that?
 
 The free version seems to only work for projects on gitlab.com. I can
 sign in, but since I have no projects on gitlab.com I can't do
 anything.
 
 This is analagous to having free* Travis CI on Github, which is also no
 use to us.
 
 Travis! -- needs Github
 Gitlab CI! -- needs Gitlab
 
 You see the pattern.
 
 *IF* the person running git.gnu.io set up a local instance of Gitlab
 CI, we could use that. Or they could set up any other CI system. Or we
 could set one up ourselves.
 
 If we're going to set up one ourselves, it makes sense to use bake,
 contributing any necessary features back to the project as they arise.
 I say that with no greater rationale than it is also written in
 Haskell. Really, if *anyone* makes *any* CI available to our project,
 that would be rad.
 
 The hard requirements are:
 
 1. Is triggered by HTTP POST requests.
 2. For merge requests, it checks out master, merges the request
 branch, runs tests, and reports results.
 3. It logs each attempt somewhere accessible.
 
 Ideally, the reporting would be *right in the merge request*, as it is
 with Travis on Github. It's actually possible this could be done
 without modifying Gitlab, if the CI system could write comments on the
 MR's discussion.
 
 * Only free as in beer, of course: Testing your open source project
   is 1% free. Seriously. Always.
 
Ok, I'm fine with whatever, we could ask Matt Lee about GitLab CI, but I
know he's busy. GitLab CI is FLO though, so we could potentially use it
without Gitlab.com — but if Bake works, then great…




-- 
Aaron Wolf
co-founder, Snowdrift.coop
music teacher, wolftune.com

-- 
Aaron Wolf Snowdrift.coop https://snowdrift.coop
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev