iOS SVN check in rules - ios

I am new to iOS development. We are using SVN for code repository.
I wanted to know whether there is a way to set some rules on code check in? i.e. suppose we have a code guideline and we want everyone in the team to adher to it religiously. We can set some rules via which automatically it can be found out whether the person has followed the guidelines or not.
Something like TFS check in policies?

You can use on server side the so called "hooks".
Most important is the pre-commit-hook
You can found them on the server inside the repository in the directory hooks
You can place any executable there and it will be called during commit. There is a svncommand called svnlook which you can use to look directly into the transaction to be committed.
In each repository there is one example for each hook SVN provides. These templates showing a sample implementation with some meanigful bash script.
more infos about hooks

Related

pre-commit check or Remote-run missing with Github setup & Jenkins

Just to quote as an example one can submit a remote-run with some tool like TeamCity (similar to Jenkins) where it will apply delta/patch on what user is trying to commit & produces result whether changes is good from set-of configured checks for that project.
With Github & Jenkins, can such validation be achieved with any plugins out there?, which will avoid breaking a build?
I know with pull-request & status check one can achieve similar end-result. But without commit/push to remote repo of Git - is there a way Jenkins can handle this validation & produce initial result ??
It isn't possible to have GitHub perform checks on data it doesn't have, so if you don't push the data to the remote server, GitHub won't know anything about it and therefore will do nothing.
Jenkins does have a REST API that you could use to do this, provided you equipped each developer with appropriate credentials. However, this is not a common situation and wouldn't be a recommended configuration.
You'd be better off with a script in the repository that users could install as a hook or invoke from a hook that would perform the testing you want. If your CI jobs run a script in your repository, then sharing code between them should be easy.
Note that you shouldn't mandate pre-commit hooks, since they can interfere with advanced users (who may make intentionally incomplete temporary commits) and they can be disabled by users. Any sort of required checks should be done as part of CI, where policy can be enforced appropriately.

Add condition to transition using script runner

I am using the scriptrunner plugin for Jira.
Is it possible to add a condition to a transition using scriptrunner?
Currently, my condition is in a script which I have manually added to the workflow.
But I was wondering if there is a way to do it automatically?
I was looking through documentation on: https://docs.atlassian.com/
I came across this method:
replaceConditionInTransition which is a method of WorkFlowManager.
But I'm unsure on how to use this.
Any help would be appreciated.
Conditions as any another scripts can be added from file system. You can store scripts in any VCS (bitbucket, github, gitlab, etc) and automatically deploy them to Jira server file system through any CI/CD system (teamcity, jenkins, bamboo, gitlab, etc).
So, as result process will be looks like. 1. commit changes in you script to vcs 2. wait a bit for auto deploy (e.g. triggered by commit) 3. done. As additional you can write any script/service/etc for commit these changes automatically if needed.
Also look at script roots it's helpful way which allows reuse any of script fragments through helpers classes.
It's rather conceptual answer basically because implementation is depends on environment, but I hope that you get at least one more point of view to solve this task.
I think that using the Java API to modify Jira workflows is pretty tough. You could dig around in the workflow editor to see how conditions are added there. Remember that you have to do this in a draft workflow and then publish it, which takes some time in large projects
I like the idea of replacing a script file as easier, if it can be done when no issues are transitioning

How to version control the JIRA changes?

I asked the following two questions in JIRA Answers, but got no reply so far:
Question 1
Question 2
Basically my question is what's the best way to make changes in a JIRA production environment.
This will be rather general answer, but this is how I do it:
I avoid modifying JIRA production files. When I need it (e.g. mail templates), I keep them under source control along with plugin in 'deploy' directory which mimics JIRA directory structure so it is possible to grap it and deploy it with copy&paste
I frequently use javascript to decorate screens with custom behavior
Schema changes, custom fields and other meta data are all created in code
Keep everything in plugin and leverage plugin versioning system. Plugin should be able to check whether there is everything it needs and when not it should be able to upgrade incrementally.
For JIRA configuration - this is the same, plugin should check whether it has everything it needs, but you can also keep configuration changes in some excel file and have it under source control
My aproach is to have everything possible in source control and modify production files only when absolutely necessary. Do as much in code as possible.

Serve custom commit-msg hook from Gerrit

Gerrit comes with a default commit message hook to insert a Change-Id in the footer. The hook defines that the Change-Id should be inserted after Issue or Bug in the footer:
CHANGE_ID_AFTER="Bug|Issue"
Now I would like to modify this so it becomes:
CHANGE_ID_AFTER="Refs|Closes|Fixes"
This is because the issue tracker in use doesn't work with Bug or Issue but with an issue identifier starting with a #.
Now of course I can apply this locally but uniformity is desired across the complete development team. It would help a lot if Gerrit would serve this modified file.
I can't seem to find anything in Gerrit's docs that describes what I would like to achieve.
Since the hook is pulled in through scp I thought I might be able to upload a modified hook the same way. This of course didn't work.
I have administrative rights to Gerrit, so that can't be the issue.

How can I have persistence Modifying a Grails plugin?

I'm developing a grails application that uses export:1.6 plugin, but for particular reasons in some cases the result of an action using services is wrong, so I had to get in the methods of the plugin and I had to make son modifications inside the plugin, trouble comes when I want to commit it in our SVN repository (because we are working in a develop team), I'm going to update the app with the plugin modified, but when another person downloads it, the original plugin is going to be originally installed. So I thought to create a new plug in, but, do you have any another suggestion? or if the best way is to create a new plugin, how can I publish it in our Repo? oris it possible to download it with my changes?
This question is similar to this one. In your case, you are better off creating a new plugin.

Resources