I have just a single instance of jenkins on a local machine which we are using to build our code. We have different project teams working on different projects, and different jobs for each project.
To eliminate the possibility of someone from one team accidentally messing up another team's job, i have created multiple jenkins users.
However, all of the users that can log on still see all of the jobs. Is there a way for certain users to only see the jobs that pertain to them?
I have searched extensively for something like this but no luck. I haven't found any plugins for this. I am using matrix based security currently, and although you can change the permissions of all the users through this, you can not apply specific permissions to specific jobs. At least to my knowledge. Any ideas?
Just to clarify, I want one of the many teams to log in to their user account in jenkins, and only see their jobs. The jobs of the other teams should not be visible, only the ones that they are assigned should be visible when they log on
The closest thing i have found for this is in the Role Strategy Plugin, there is a user-based job filter
Turns out there is a feature already in jenkins for this, no plugins necessary!
In the Configure Global Security section in Manage Jenkins, click "Project-based matrix authorization strategy".
Then you can configure permissions in the job configure screen for that particular job by clicking "enable project-based security".
Now you can configure your Jenkins so that "Joe can access project A, B, and C but he can't see D".
Related
I would like to setup a sandbox project in my school GitLab server (self-hosted, free), that all users, especially new ones, can use to test whatever they need.
How can I add all users to the same project?
I already read this releated question (that asks the opposite), but it only partially help; the most useful answer tells me to use the API, which is good if I want to add all current users to a project, but I also want to add new ones.
Is there a way to add a user to a project, triggered by that user being confirmed?
One builtin method would be to use system hooks. For example, you can create a hook that responds to user_create events and adds the user to the project.
Another way may be just to run a scheduled CI pipeline that scripts this or similar automation (e.g. cron job on the server or whatever).
You can use the users list API to enumerate all current users in your GitLab instance (requires admin privileges). You can also use the project membership API to enumerate all members of the project. You can compare the two results to find any users that need to be added.
Pseudocode:
project_members = get_project_members(project_id=1234) # project members API
for user in get_all_gitlab_users(): # list users API
if user not in project_members:
add_project_member(user=user, project_id=1234)
I am working on a B2C project.
We are using customized bundle implementation in our project.
However we were struggling with making bundle synchronization work.
With some effort, we managed to find the ImpEx to synchronize the Bundle:
UPDATE CatalogVersionSyncJob;code[unique=true];roottypes(code)[mode=append];
;$syncJobCode;BundleTemplate,BundleTemplateStatus;
However, I am worried whether this will also synchronize the ChangeProductPriceBundleRule available out of the box.
Also how do I synchronize this from backoffice?Is running this cronjob from the Backoffice the only solution?How do Backoffice users see a Synchronize button?Is creating a separate node necessary?
How to synchronize from backoffice?
Go to Backoffice
System -> Background Processes -> Jobs
Search for your sync job and use Sync button for panel
Is running this cronjob from the Backoffice the only solution?
You can schedule this job to run on specific interval (Cron Job)
Is creating a separate node necessary?
Not necessarily but you can customize if you want.
Hope it helps!
We are looking at removing developers from production and want a simple kind of deployment management tool. One suggestion that some members are using with SalesForce is Jenkins. I have never used Jenkins or any kind of deployment tool before. I normally just copied my code from IDE and updated the file in the SuiteScript file cabinet.
Does Jenkins work for NetSuite? Or what do you recommend for this purpose?
We are planning to use Bit Bucket (which runs Git in the background) as our version control in case that matters.
Thank you for any help
IMO the greatest challenge in integrating with any CI environment(be it Jenkins or any other) is the fact that you can move code files from one system to another using code/APIs but, NOT things like scripts, custom records, fields its deployments , etc. for which you need a bundling process and hence, manual intervention.
NetSuite in recent Suiteworld 2015 said that its coming up "Change Management" which would allow you to put everything that is part of your app to version control system such as git. Please see SuiteAnswer Id 42387, when this feature is rolled out, you can integrate with your CI tool to automatically copy/deploy your app details to an another NetSuite account and run your tests there and accordingly pass/fail your build.
Why do you want to remove developers from Production? This will severely hamper their ability to create solutions for your NetSuite account and will create a ton of overhead for them.
If you must have them out of Production, then probably your "best" option would be to have them build their solutions in Sandbox and then use SuiteBundles for deployment to Production. A Production Admin would need to update the appropriate Bundle(s) for all Production migrations.
NetSuite has also built a SuiteCloud IDE plugin for Eclipse which allows uploading and downloading files (no copy-paste necessary), so if you're not using that I would recommend it.
We are using Jenkins for our own internal automated testing, but not for deployment into NetSuite. I do not know if someone has already built a NetSuite plugin for Jenkins; it is likely you would have to build your own file upload mechanism using the NetSuite Web Services SOAP API, but that would still only allow deployment of source files. Developers will most likely also need to be creating and updating custom records, fields, lists as well as Script records and Script Deployment records, which you will not be able to do through Jenkins or any other tool that I know of.
I am new to Liferay Portal and am using 6.1 CE. I am trying to find a way to allow multiple developers to make changes to a single Liferay Portal simultaneously. I know that I can set up a Staging environment and allow all developers to log into the Live site and develop inside the Staging environment on that instance. I also know that I can set up remote staging - allowing a developer to make changes on a separate staging environment (on a different Liferay instance) and then remotely publish the changes to the Live site. I also know that multiple developers can each log in to that single remote staging environment.
What I want to know is this: Can I set up multiple Liferay instances as remote staging environments (one for each developer) that all publish to the same Live Liferay Portal Instance (separate from all staging environments)? If so, will changes made in one remote staging environment and then published to Live be reflected in the other remote staging environments? E.g., if a page is changed in Staging Env. A and published to Live, will the change be seen in Staging Env. B, or would it be oblivious to the change?
I hope the question/scenario makes sense. If further clarification is needed, please let me know so that I can add detail. Thanks in advance.
Starting with Liferay 6.1 you're able to work with page variations - effectively branches of your content, so that you have multiple parallel versions that you can work with. This seems to come closest to what you describe, although it might not be an exact match.
You can also manually export/import pages and articles and move them around, but I have the feeling that you're looking for an automatism that works more like a distributed versioning system - I doubt you'll find that anywhere. A certain amount of manual work to disambiguate conflicts will still remain - and the interface for that is typically a bit hairy.
I have a team that will be using CruiseControl for continuous integration, and CC will be running on a Linux server. More than one team member may need to access the CC configuration itself: changing how tests are run, changing notification rules, etc.
What is the best practice for this?
My first thought was to set up a cc-users group, then make a shared directory somewhere (such as /usr/local, I suppose, or a new directory like /projects), where the directory has r/w for the group.
Am I missing any complications with this plan? Obviously, I've never been in charge of such a project before, otherwise I wouldn't ask such a question.
FWIW, my intention is to have all the cc configuration files under mercurial so we can roll back in case of breakage.
I have version-controlled the whole of cruisecontrol configuration, along with the project specific config files underneath it.This way, the write-access can be controlled per requirement, using your source control tool's access control method (in our case subversion) thus providing tracking as well. Whomsoever needs to make a change can checkout the file config.xml in their own workspace and make their changes and then commit. You may want to consider the same approach.