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

New experimental stress test job / Access permission #331

Closed
santigimeno opened this issue Feb 12, 2016 · 5 comments
Closed

New experimental stress test job / Access permission #331

santigimeno opened this issue Feb 12, 2016 · 5 comments

Comments

@santigimeno
Copy link
Member

Hello!
In the last (non-official) testing WG (https://github.com/nodejs/testing) meeting, a strategy to stress tests was discussed. See: https://github.com/nodejs/testing/blob/master/doc/wg-meetings/2016-02-05.md#single-stress-testing-of-parallel-tests-in-parallel and the related issue nodejs/testing#3. It was suggested to make a copy of the current stress test job to experiment and also ask for access for me. Would that be possible?
Thanks!

@bnoordhuis
Copy link
Member

@santigimeno Aren't you about to be onboarded? You'll have full access after that.

@orangemocha
Copy link

I think the question was about having job write access to Jenkins, to allow for experimenting with the scripts. Currently, that is restricted to a smaller set of collaborators, due to security considerations.
@nodejs/build @nodejs/jenkins-admins not sure if we have a well defined criteria for granting trust. Thoughts?

@jbergstroem
Copy link
Member

The build group has access to create jobs but not to credentials/jenkins admin. Would that suffice? I mean, we could give similar access to the testing group.

@orangemocha
Copy link

I believe it would suffice. Still, we need to answer the question about trust. Tagging for wg-agenda.

@orangemocha
Copy link

We had a long discussion about Jenkins access and security at the last Build WG meeting. Regrettably, at this time we are not prepared to grant the requested level of access.

Being able to edit jobs gives a user more ability to screw up our CI infrastructure (whether maliciously or inadvertently). This is hence restricted to a small group of users (nodejs/jenkins-admins). While it would be great to have more people who can help manage the infrastructure, we need to consider the security risks and maintain somewhat strict criteria for granting access. Even though not formally defined, those criteria could be summarized as follows (this is mostly my take on it):

  1. How long have you been a Node contributor / collaborator?
  2. Are you also participating in the Build WG?
  3. Is your work on Node affiliated with a company / would you lose your job if you purposely tried hacking our infra?

One idea we discussed was to create a separate instance of Jenkins (with a smaller number of slaves), which could be used for experimentation by a broader group of people. As a side note, this would also be useful for current jenkins-admins to test global configuration changes (e.g. Jenkins or plugin upgrades) before rolling them out to the main Jenkins. The jenkins-admins could then review changes made in the experimental instance and integrate them into the main Jenkins. A GitHub workflow is also imaginable.

Due to resource constraints - mostly people's time - at this time the Build WG has not agreed to move forward with the experimental Jenkins instance. However if anybody (@nodejs/testing ?) wanted to set this up and maintain it, we would be glad to offer mentorship and a few machines.

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

5 participants