nodejs / automation Goto Github PK
View Code? Open in Web Editor NEWBetter automation for the Node.js project
Better automation for the Node.js project
See nodejs/TSC#491 (comment), it would be great if mhdawson/create-node-meeting-artifacts could pull the team lists from GitHub, probably by using ncu-team
.? The current lists is here.
cc/ @mhdawson @richardlau
How could we automate the process of creating the staging branches?
An idea to start:
perhaps we could use labels to mark issues that are approved for backporting and a bot could automate cherry-picking it to a staging branch. If it does not land cleanly it adds a label / pings a backporting team
edit:
I've pivoted this issue to be about the LTS branches rather than the release process, as they are slightly different problems
We could use the github bot to listen to the org's membership
event and automatically open a PR to update the member list in readmes.
Just an idea, implementation still should thought of (how would the bot know which teams are relevant and which readmes need update)
I've searched the organization for "testing" repos and have not found one. We should have a repo forking from the nodejs/node
repo for testing bots/scripts. Any other ideas on how this should be managed?
The earliest I remember this being brought up was by @refack
A commit queue is a process for automating the landing of commits and managing of multiple branches.
This is a potential way to fix #2
For inspiration here is the design doc for the Chromium Commit Queue
The CQ polls rietveld for CLs that are ready to be committed. The Chromium's fork of Rietveld has a 'Commit' checkbox. When the author or the reviewer checks it, it will be included in the next poll. Once the CQ learns about the CL, it verifies the author or one of the reviewers approving this CL is a full committer, then runs the presubmit checks, then runs try jobs and then commit the patch on the behalf of the author, faking its credential. The whole project is written in python.
https://github.com/nodejs/core-validate-commit and https://github.com/nodejs/node-review (EDIT: also https://github.com/nodejs/branch-diff and https://github.com/nodejs/changelog-maker) have already been moved into the Node.js orgnization and there will be more repos get transferred later. (also the github bot is probably going to be handed over to the automation team as well). We need to figure out how to organize the accesses of these projects.
Including write access(commit) and admin access(add new people).
A few options that I have in mind:
If we do want to adopt the monorepo idea(see #1 (comment)), then after the transition we can probably just go with option 2.
So first thing to do is to add the foundation account to the collaborator list as a safety net. We should keep the existing npm collaborators, other than that, I can think of a few options:
Personally I would prefer to see the releasers turn on 2FA on their npm accounts as well.
So...
๐ if you want subteams with repo/npm accesses
๐ if you want a big team with repo accesses, and small teams of releasers for each project
Or discuss in this thread about any other ideas that you have!
Wanted to ask if the make-node-meeting repo is within the scope of automation. My thought is yes - it's a tool we use for automation as WG organizers/team members. It was just recently pulled in like several other tools, and I think it fits very well within the scope of Automation.
https://github.com/Azure/brigade
This is really interesting tool for writing CI / CD pipelines using k8s with JavaScript (node...ish).
I wonder if it could be a cool way to build some tools. I can likely stand up a test cluster for us to experiment with
Hey team!
I'm currently working on the translation of nodejs.org to french, and I came across the description of the build WG.
It says it's purpose is "to create and maintain a distributed automation infrastructure."
Given the recent founding of our team, I know things aren't always pretty clear, but I think I remember that we are a separate team, not a subteam of the Build WG. Am I correct?
If so, shouldn't we try and see with them if we can rework their description to better suit their purpose?
And on a side note: if we're not a WG, how do we stand in the organization chart? And do we want to promote our work, and ask for a section on the WG page?
I'd say yes, but hey, I'm just one in a team! โจ
Hope I'm clear enough...
Cheers!
Like nodejs/node README does.
- version: REPLACEME
pr-url: REPLACEME
When originally authoring a PR that has API doc changes, you can't know the pr-url apriori. So this issue can't be trivially linted.
We should either:
ncu
before landingREPLACEME
replace tool for releasers, that deduces the pr-urlThere was a discussion in the moderation repo about managing the bans (reminders etc).
I proposed that if needed, I can help in building an app to (un)block users, set reminders, maybe later automatically detect bad behaviours etc.
GitHub API supports organization ban related CRUD operations, but as @ChALkeR and @ryanmurakami pointed out, we have to figure out what are the security implications (e.g. @ChALkeR noticed that such operations need the admin:org
scope which is quite powerful).
I opened this issue for discussion. I worked with GitHub API in the past and help if needed, maybe I can help. ๐
This idea started in #1 (comment), and seems to receive some popularity within our team, so I think we can open an issue dedicated to this topic.
(...that I can think of)
Please indicate your approval/objection towards this idea in this thread, and discuss about how we are going to structure the monorepo if this idea sounds good to you.
Taken from nodejs/TSC#392 (comment)
In the core repo we are experimenting with the use of CODEOWNERS
file. It's going to require some maintenance and iteration to get correct. At some point, we may want to have some tooling to automate maintenance and auditing of the file so that it is correct.
There are also other ways the CODEOWNERS can be leveraged... For instance, ncu could include a git
command that uses the CODEOWNERS file to identify who would be notified for any given set of commits.
So, this happened: nodejs/node#19438 (comment)
(Someone accidentally used the wrong PR number when starting a CI job.)
Surely this isn't the first time this has happened nor the last time this will happen.
Would be awesome if we could either:
have git node land
check the CI parameters to make sure they match the PR number? (That's a big request and would probably be sloooooow.)
have a tool to start CI jobs that would somehow reduce the probability of this sort of thing. Not sure what that would look like to be honest.
This may be Too Big To Solve. Feel free to close. Just wanted to put it out there for consideration. Thanks.
https://github.com/nodejs/node/releases
There is an api for editing a release... so this seems pretty reasonable
https://developer.github.com/v3/repos/releases/#edit-a-release
One small automation idea: when a PR lands from a brand new contributor, it would be cool to have a Twitter bot that automatically posts a thank you tweet with a link to the PR. Might be a cool way to give some recognition.
IMPORTANT: if you are not already a member of the Node.js organization, please read #4 (comment) about the purpose of this team, make sure to read our Code of Conduct and agree on it before you reply.
https://github.com/kubernetes/test-infra/tree/master/prow#prow
Prow is a Kubernetes based CI/CD system. Jobs can be triggered by various types of events and report their status to many different services. In addition to job execution, Prow provides GitHub automation in the form of policy enforcement, chat-ops via /foo style commands, and automatic PR merging. See the GoDoc for library docs. Please note that these libraries are intended for use by prow only, and we do not make any attempt to preserve backwards compatibility.
Hello.
I propose to create a project with common resources and utils for all the @nodejs/automation projects.
It would contains .editorconfig, eslint configuration files, gql queries and fixtures...
With this we get a centralized management of common resources and we avoid repeating files with the same content.
It could work like a dependency with a postinstall script that makes symlinks.
What do you think? I you give me the approval I start working on it.
Please comment your impressions! ๐
Small suggestion:
The npm install issue we had earlier today had me thinking:
Shouldn't we test our releases in some way with earlier Node releases?
I mean, I understand there's a great tool for that in the project, so maybe we could take advantage?
Not necessarily for really old versions, but at least current lts + latest version?
Maybe dumb idea, but at least we can talk about it ^^
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.