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

Shared CI configurations #321

Closed
dominykas opened this issue Feb 27, 2020 · 6 comments
Closed

Shared CI configurations #321

dominykas opened this issue Feb 27, 2020 · 6 comments

Comments

@dominykas
Copy link
Member

dominykas commented Feb 27, 2020

Origin: #280 (comment) and #318.

Travis now supports includes. I'm not too familiar with other systems, but I'm sure they have something too. It would be nice to provide an official set of includes that people can just take and use, e.g. "On Travis, use all LTS versions starting with v10 + current version" (implementation details / naming convention / folder structure to be fleshed out with the first impl).

So we need to make some decisions first:

  1. Where do all of these things live:
    • it could be one repository, with a folder per CI system
      • this might not work, if the CI system expects files in the root folder of the repo
      • this might result in lots of churn in the repo
    • it could be a repository per CI system
      • this does add admin overhead for multiple repos
      • this does add overhead for keeping the structure of the repos the same
  2. The actual names of the repository (repositories?)
    • could there be trademark implications?

Not sure if we need to discuss governance? Apparently this WG is not "chartered" whatever that means - does that have implications on decision making? Someone needs to take ownership of these configurations and we'll probably want to define some rules (e.g. all the include URLs must keep on working as long as we're on GH)?

I'd like to get something out very soon (i.e. next 2-3 months?) - I wonder if that is possible and how fast can we gather enough consensus?

@dominykas
Copy link
Member Author

dominykas commented Feb 27, 2020

Keeping my suggestion outside of the intro post. I think my preference is a repository per service, with one extra repository for meta discussions - primarily because it's hard to expect people to be knowledgeable about all the various CI systems, but also because it allows fine-grained merge access, so I'd propose:

  • nodejs/ci-config - meta discussions, setting the patterns for all the other repos
  • nodejs/ci-config-travis, nodejs/ci-config-circle - per provider repos

Quite possibly "ci" is too broad a term and maybe the name should indicate the intended audience (package maintainers) better? But I'm short of ideas right now :)

@ljharb
Copy link
Member

ljharb commented Feb 27, 2020

I’m happy to set up and maintain that, if it’s what we want to do, since I’m already doing it in https://github.com/ljharb/travis-ci.

@mhdawson
Copy link
Member

I don't have any better ideas for the naming.

@dominykas dominykas added the package-maintenance-agenda Agenda items for package-maintenance team label Mar 1, 2020
@mhdawson
Copy link
Member

Agreed to ask for these repos in the Package maintenance meeting today:

  • nodejs/ci-config-travis
  • nodejs/ci-config-github-actions

@mhdawson
Copy link
Member

Issue for request: nodejs/admin#477

@dominykas dominykas removed the package-maintenance-agenda Agenda items for package-maintenance team label Mar 11, 2020
@dominykas
Copy link
Member Author

We now have ci-config-travis and the repository for ci-config-github-actions is open, so unless there's objections I'll close this in a week or so.

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

No branches or pull requests

3 participants