The problem i am trying to solve is where developers change files without going through the proper channels. The developer should be able to make the change himself but only after his work was approved, since the code is used in a lot of projects
I found this link that also describes my problem:
http://www.p4ideax.com/ideas/694/temporary-permissions
One way to do it is to have only the architects have access to the files and then granting the developer temporary access. Maybe the permission can be linked to a specific job in perforce. The only way i can see how to do that is by adding the files that the person should be able to change to a new field in the jobs template ( done by architect ). Then have a server app dynamically call p4 protect and manage the permissions table. Then when the job is closed the permission is revoked. The server app could be the bugtracker software.
Is there an easier way or even 3rd party software out there that can solve the problem?
I know that another way to solve it is to put these sensitive files in a branch and then only allow the architects permission to merge into this branch. This solution feels a bit heavy handed.
Any suggestions would be helpfull
This is something that could certainly be done with a pre-submit hook. There are examples at Perforce Depot.
My thinking would be to reject submits for files in that section of the depot that didn't have a job that was on the "approved list". You could create the approved list in a number of ways, although a simple one (if you're using Perforce globally) would be to put the job list into a file under repository control and then have that list be available only to the architects.
The pre-submit trigger would then basically need to:
- If the files being submitted aren't in the protected tree, let the submit happen
- Grab an r/o copy of the file from the depot
- Grab the job list from the submit
- grep the job against the list
- If the job is in the list, let the submit happen
- Reject the submit with an appropriate error message
Related
Looking to know if there is any way, that I can add gatekeeping rules to prevent code from getting checked in until there is atleast 1 approval on the CL?
I am not looking to add locks, as that prevents anyone from doing code changes.
The standard solution is to use Swarm (a free tool that integrates with Perforce) for code reviews:
https://www.perforce.com/manuals/swarm/Content/Swarm/home-swarm.html
Swarm tracks reviews of shelved changelists, and comes bundled with pre-submit triggers that block submit until the changelist has been approved.
Does GitHub have public access restrictions?
Example file:
https://raw.githubusercontent.com/vuejs/vue/dev/package.json
What will happen if a million users download this file?
This is from a GitHub employee in regard to "raw" file access:
I spoke with our engineering team and learnt that there's a limit of
5000 requests per hour per IP address. Additionally, due to internal
routing and caching, that 5000 figure isn't going to be exact. We may
accept more but it's sometimes possible that we'll accept less too.
As was pointed out to me, if you're at risk of hitting this limit,
then you're probably doing something wrong and there's a better way to
obtain or even store the file.
After 1+ year of waiting, they still haven't confirmed if this is accurate or updated Docs, so I'm guessing routing requests via the GitHub API and using tokens might be more reliable.
Ref: https://github.com/littlebizzy/slickstack/issues/180
Ref: https://github.com/github/docs/issues/8031
I don't think there is any limitations. i have deployed many simple static website on github which gets accessed by a lot lot of users. At times, i have seen it being slow a lil bit(during heavy traffic). But limitations, there is not any limitations.
GitHib definitions for "public" code access are very vague online so hope this helps anyone who was as confused as I was!
GitHub confuses "public" with "open source".
The first is a permission-based access designation and "git" workflow strategy on GitHub, the latter a licensing issue and a broader code access paradigm. But they mix the two together to create a new workflow on their website for how code gets shared using source control git. That confused me.
In general, GitHub "public" repositories means close to the same thing as "open source" in terms of access and use. In general it means any public GitHub repo can be viewed, downloaded, forked, etc. But anything beyond that starting with "write" access on the owners original code base requires the "owner" of the repo to add that person as a "collaborator". I interpret that to mean unlimited and unrestricted access to copy, download, and view your code by any known person, machines, process., etc.!
However, the sample open source licenses (like GNU 3.0, etc.) they recommend you create or use for your projects might legally limit some use of your code. By they are not going to help you enforce or limit that. Once your code is online there is no script or lawyer or enforcing entity that can stop any of that. That is why its called "open source". I have used the GNU "free beer" license for distribution of my personal code before and like it though Ive never seen a need to enforce it as far as limiting much. The main thing it would help with is making sure you remain copyright owner on the code in the USA and in a few other countries....AND....stop big corporate entities from taking your code and claiming copyright, limiting free use, etc.
HOW GITHUB DEFINES "public"
Note: The following applies to GiHub individuals, not organizations or enterprise accounts which have much more granular control over GitHub code projects and repositories.
When you go public on GitHub, meaning you turn your repo to "public" access, you are allowing some form of "open source" or "free" use of the code. In the "git" world this could be many different things as far as both access and use. But in the GitHub world it implies full rights for people or machines to have "read" access by default when your repo is "public". What does that really mean as far as access and use? Well it means:
Anyone or any machine can view the code (they call it "visible") or code files online for free, including manually copy the code in a web browser. That means unlimited views and use of your code.
Anyone or any machine can "download" the code via their code download link. In the GitHub world that means a zip or other compacted wrapper of all the code files into a format you can download in one file. That means unlimited downloads of your code.
Anyone or any machine can "fork" (not "clone") the code. In the GitHub world that means GitHub copies the code and sticks that copy into your GitHub online web account, if you have one. This copy is a "fork" to them, though traditionally that's not what "forked software" means. With this copy a user can then download a "clone" of the forked code to their local machine and start modifying it and push changes to the GitHub forked copy. They cannot do anything with those changes as far as changing your original code base without you setting them up as a "collaborator". But it does includes sharing that with the world as well, which increases views and downloads of your code base to even more people you cannot track! So "public" means all the public clones, mirrors, or forks can be downloaded and shared as well.
BTW...."forking" the code in the GitHub world means copying the code with all the commit and git source history to their GitHub account so later - with more permissions granted by you - they can submit your code back to the original repository code base with a pull request for changes.
This confused me at first, as I thought a "public" repository at GitHub meant anyone can "clone" the original repo to their local box only, which would allow anyone to use a local copy of the GitHub remote repo and pull code updates. In that model they could never do push or pull request updates without additional permissions, which makes sense, but also could never share copies of your code online (unless they explicitly created a new repo at GitHub from your code base).
But that is not what "public" means to them. They want people to directly fork or copy projects into the public site and modify code on their platform using forks. That is the workflow GitHub encourages on "public" projects on their site. This allows any user or machine to make a full copy of everything and do whatever they like to that copy, including sharing and distributing it to others. This is why "public access" does open up your code to lots of crazy things including copies of your code spreading quickly across GitHub with no way to know how many people have truly used it in projects or even care to contribute back to your original.
Personally, at all the companies I have worked at that use Git, I have never seen that type of model for distribution of repositories. We always cloned a master in a development environment and built branches remotely and locally from there. It feels like this was not thought through as it opens up distribution of your code into millions of versions of forks most people never asked for, cannot sync, and will forget about over time.
The way we do pull requests at my company, we require 5 specific people to be on all pull requests into Repository A, and a different list of 4 people on all pull requests into Repository B. It's kinda a pain to remember which names go where and not leave anyone out.
Is there a way I can create an alias or something that will autofill in the review request fields that will add all the appropriate people?
For instance, I want to create RepositoryAReviewers and RepositoryBReviewers, and then whenever I pull request to either repository I can just put the alias in the review request field and hit submit. Does this exist?
What you want to do is create teams for these groups. For example, when I wish to merge code at work, I use the my-company/my-team-reviewers team, which pings all of the reviewers on my team. my-company is the name of your GitHub organization.
If you additionally want to require all reviews for a certain repository (or certain files within that repository) to be from a certain team, you can use the CODEOWNERS file to do so. That's especially useful if you have a core team for a project that you always want to do reviews, or if teams are responsible for certain subsystems.
A CODEOWNERS file that affects the entire repository would look like this:
* #my-company/core-dev
I had the same problem last week and made a simple chrome extension to create/save lists of usernames and bulk-add these lists as reviewers on my currently open PR
https://chrome.google.com/webstore/detail/github-reviewer-groups/mmgjipidkhkfimmfgcgklooinlcfonah?hl=en&authuser=0
It's open source too, so feel free to try improving it. The repo is here: https://github.com/KhaledAylii/Github-Reviewer-Groups/tree/master
Refresh NetSuite sandbox from production (code only)
I realize that we can refresh out sandbox from production but we don't want to refresh the entire sandbox, instead we want to refresh NetSuite SuiteScript, NetSuite Forms & UI Objects.
NetSuite's proprietary infrastructure/code and challenge it brings
I resisted asking this question for several weeks thinking it was too basic but it doesn't appear that way. After working with NetSuite for a while it has become clear that the line between source code and data has become blurry and it's my opinion this is exactly what makes refreshing code challenging.
I've also learned that storing NetSuite code in version control software is next to impossible (for all code) and this leads me to believe that my desire to refresh code only might be impossible as well. I have to wonder how IT shops that are encumbered by SOX compliance issues are able to satisfy auditors when it comes to controlling and modifying the business logic.
The real question and reason for refreshing the sandbox code
My motivation for refreshing sandbox code is the fact that we are encountering unexpected behavior in our sandbox accounts with certain forms (invoice & estimate) where custom tax fields (Ava-Tax) mysteriously moved from the items tab to a tab that contains transaction body fields! The form appears to not have been updated by anyone in over a year and there were no packages installed in the sandbox that might have broken the form.
If I cannot refresh source code is there a way to determine how a NetSuite form became corrupted knowing that the NetSuite Form is stored in a proprietary way and with no apparent source code available? I understand most of the NetSuite code is JavaScript that runs on both the server and client and there are parts that are unavailable to anyone outside of NetSuite.
Any solutions or suggestions are welcome and appreciated.
It is not at all impossible to store NetSuite code in Source Control. We use git to track all of our NetSuite source, and we follow a process similar to gitflow. Our master branch is always kept in sync with Production. Anytime we push code to Production, that gets merged from its feature/fix branch up to master and tagged as a release. If we want to roll back, we just revert master back a commit and upload the whole project to the File Cabinet. Then, if we want to refresh a Sandbox to match Production, we simply checkout master and upload all of that to the Sandbox.
Sandboxes themselves are much more difficult to keep in sync with a single branch in source because we are constantly developing there on separate feature branches.
If you do not already have such a system in place, all you really need to do is download the zip of your SuiteScripts folder from the Production File Cabinet and upload that to your Sandbox.
This isn't source control, but you can use SuiteBundler to copy items between accounts. SuiteBundler allows you to choose from a lot of things like forms, scripts and custom records. Later you can uninstall the bundle or dissolve it into the account.
It's not so easy to explain in few words, here but: You can use a deployment account to get things work properly. So you continuosly work on dev accounts and use multiple bundle / bundle version for follow branches/Versions of customizations. You update bundle from dev to deploy account only when a version is stable and production envs always install / update bundle version from deploy (not from dev). Since bundles are versionable and infinite, you can use git + dev + deploy account for manage Cvs. For get a versionable version of a form just add &xml=t in url in any form. But this is read only
I'm using Perforce version control system (http://www.perforce.com/) and would like to format source code files (mainly XML) when developers submit their files to Perforce. I know that Git and SVN allow script hooks that provide for that.
Is there a way to change files that are being submitted to Perforce using some kind of a hook?
How can I do that on Perforce?
Thanks!
When I've done these sorts of policy-enforcement tools in the past, I've done it post-commit.
That is, after the submit completes, my tool retrieves the newly-submitted files, re-formats them according to the policy that I'm enforcing, and submits the re-formatted files as a follow-on change.
I do this by writing a tool that monitors changes similarly to the way the change review daemon monitors changes, so that the tool notices new submits and reviews the new files to see if they comply to the organization policy.
I generally have the tool perform a "revert -a" prior to the submit, so that if the files were formatted according to policy by the original developer, no second submission occurs.
I actually think this is a better approach than trying to do it during the submit:
The change that is submitted is exactly as the user provided it, with the identical content as provided by the user
The modifications that are due to the tool are clearly visible in a separate submission, which makes it very easy to recognize when the tool has gone astray and damaged the file during its re-formatting (such tool bugs do occur).
The net effect, overall, is the desired one: the files at the head of the branch are formatted according to company policy.
A Perforce trigger is what you need.