What is the best practice for automatically-generating ruby documentation as part of a git commit workflow? We'd like to automatically generate new documentation whenever a commit is merged into master.
Use Git hooks.
If you want it to run on the client side, use a post-commit hook. Essentially, registering a hook (by storing it in .git/hooks) makes Git call an arbitrary script you provide after each successful git commit. Your script can then call RDoc or YARD to generate docs into some output directory (outside your source code repository, of course).
Alternatively, you can have it run on the server hosting your Git repo, using a post-receive hook. This will run after you push to the server's repo. For example, you could use this to automatically upload the new docs to /docs/dev/ on your project's web server.
For detailed instructions, see the chapter on hooks in the Git manual.
Related
I want to implement a generic CI pattern using Argo Workflows. One Workflow is triggered by the git server using an Argo Events webhook. After validating the signature, the repo is cloned and a custom workflow from the git repo is started (with a fixed name, e.g. .argo-ci.yaml). The Workflow of Workflows pattern is recommended to be implemented using the template.resource field. When using the manifest key, I can use input variables as shown in the example. However, variables are not evaluated using manifestFrom, which I would need to start the Workflow from git.
For a CI use case, the child workflow either needs to be passed the git repo artifact or at least the git revision as a variable so that the Workflow can clone and checkout the correct sources for which the CI was triggered. Both does not seem to be possible as the manifest from template.resource.manifestFrom is applied as-is without templating options.
I have a ruby library which 'measures' a text file and dumps the measurements to a file. I use Travis CI to show these results whenever someone makes a pull request to change the file in a github repo. My goal is to make a pass/fail check based on whether metrics are 'Improving'.
When a pull request is submitted and Travis CI runs my rakefile, I want to compare my metrics in the pull request branch to the metrics of the master branch.
Assume I have a rake task which runs metrics on a text file and spits out the results, and that I can compare two result files.
task :run_metrics
ruby "lib/metered_object.rb"
#metered_object= MeteredObject.new(File.expand_path("./list.txt"))
#metered_object.set_targets({"metric1" => 10, "metric2" => 500})
#metered_object.display_metrics >> pull_request_output
#metered_object.compare_metrics(pull_request_output.txt, old_metrics_output.txt)
end
How should I use git and rake to either store and retrieve old_metrics_output.txt, or generate a new metrics file for master, in order to compare the newly created pull request metrics to it?
Bonus points if there's a common name for this pattern/practice I have yet to discover.
Travis CI pulls only the specific branch you are testing, so in a PR build of branch feature to master, git checkout --branch=feature ... is done in the start of the build.
If you want to compare to master, you would need to fetch the master branch as well. This could probably be achieved by git fetch --branch=master --depth=3.
After that, you can use the normal tools you need to make the compare.
Please note that if you are on a private repository, the credentials used to clone the repository initially, will have been removed at the moment where you can fetch. If that is your case, have a look at the docs for possibilities to authenticate your interaction with GitHub.
Following on from this post of mine:
API Management with GIT
I have an API management instance running. I know API management has its own GIT repository.
I can successfully clone, change and push changes up to my API management GIT repository.
I am also running Octopus deploy and am trying to use this:
Git Push
and this:
Git Pull
To pull my code from my companies GIT repository and push to the APIM GIT repository.
The thing is, these to plugins fail immediately with an issue not being able to find file paths on the Octopus server. Also, these were written in 2014.
Is there a recommended better way to pull from your companies repo and push to APIM repository? Also, if I am pulling to Octopus, where does the code get stored before it is pushed to APIM?
In the end, I think this plug in is out of date. I ended up writing my own PowerShell GIT bash and it works a treat.
I get the APIM json code from my companies source control then push it ti the APIM GIT repository and publish it using PowerShell.
For anyone who has this issue in the future.
The cause is most likely you are trying to use the GitPull step from the octopus server, while the code behind the step makes reference to this parameter $OctopusParameters['Octopus.Tentacle.Agent.ApplicationDirectoryPath'].
This parameter seems to return an empty value. I have not tried running from a Deployment Target.
The git clone directory could be another parameter/variable specified
I am raising this with the Octopus team.
We have a maven project on github for which we use Semaphore-CI.
Each time we merge a PR, the person who merges it is responsible for deploying a copy to our public package repo, incrementing the version number and pushing it directly to the code repo.
I was wondering if there is a way to automate this. Any ideas/suggestions are highly appreciated.
You could use Semaphore's custom commands to add the steps for pushing to this other repository.
Ex:
git remote add public_package http://example.com/public.git
git push --mirror public_package
My Google-fu is failing me for what seems obvious if I can only find the right manual.
I have a Gitlab server which was installed by our hosting provider
The Gitlab server has many projects.
For some of these projects, I want that Gitlab automatically pushes to a remote repository (in this case Github) every time there is a push from a local client to Gitlab.
Like this: client --> gitlab --> github
Any tags and branches should also be pushed.
AFAICT I have 3 options:
Configure the local client with two remotes, and push simultaneous to Gitlab and Github. I want to avoid this because developers.
Add a git post-receive hook in the repository on the Gitlab server. This would be most flexible (I have sufficient Linux experience to write shell scripts as git hooks) and I have found documentation on how to do this, but I want to avoid this too because then the hosting provider will need to give me shell access.
I use webhooks in Gitlab. I am unfamiliar with what the very basics of webhooks are, and I am unable to locate understandable documentation or even a simple step-by-step example. This is the documentation from Gitlab that I found and I do not understand it: http://demo.gitlab.com/help/web_hooks/web_hooks
I would appreciate good pointers, and I will summarize and document a solution when I find it.
EDIT
I'm using this Ruby code for a web hook:
class PewPewPew < Sinatra::Base
post '/pew' do
push = JSON.parse(request.body.read)
puts "I got some JSON: #{push.inspect}"
end
end
Next: find out how to tell the gitlab server that it has to push a repository. I am going back to the GitLab API.
EDIT
I think I have an idea. On the server where I run the webhook, I pull from GitLab and then I push to Github. I can even do some "magic" (running tests, building jars, deploying to Artifactory,...) before I push to GitHub. In fact it would be great if Jenkins were able to push to a remote repository after a succesful build, then I wouldn't need to write my own webhook, because I'm pretty sure Jenkins already provides a webhook for Gitlab, either native or via a plugin. But I don't know. Yet.
EDIT
I solved it in Jenkins.
You can set more than one git remote in an Jenkins job. I used Git Publisher as a Post-Build Action and it worked like a charm, exactly what I wanted.
would work of course.
is possible but dangerous because GitLab shell automatically symlinks hooks into repositories for you, and those are necessary for permission checks: https://github.com/gitlabhq/gitlab-shell/tree/823aba63e444afa2f45477819770fec3cb5f0159/hooks so I'd rather stay away from it.
Web hooks are not suitable directly: they make an HTTP request with fixed format on certain events, in your case push, not Git protocol requests.
Of course, you could write a server that consumes the hook, clones and pushes, but a service (single push and no deployment) or GitLab CI (already implements hook management) would be strictly better solutions.
services are a the best option if someone implements it: live in the source tree, would do a single push, and require no extra deployment overhead.
GitLab CI or othe CIs like Jenkins are the best option currently available. They are essentially already implemented server for the webhooks, which automatically clone for you: all you have to do then is to push from them.
The keywords you want to Google for are "gitlab mirror github". That has led me to: Gitlab repository mirroring for instance. There seems to be no perfect, easy solution today.
Also this has already been proposed at the feature request forum at: http://feedback.gitlab.com/forums/176466-general/suggestions/4614663-automatic-push-to-remote-mirror-repo-after-push-to Always check there ;) Go and upvote the request.
The key difficulty now is how to store the push credentials.
I solved it in Jenkins. You can set more than one git remote in an Jenkins job. I used Git Publisher as a Post-Build Action and it worked like a charm, exactly what I wanted.
I added "-publisher" jobs that run after "" is built successfully. I could have done it in one job, but I decided to split it up. The build jobs are triggered by a web hook in GitLab; the publisher jobs are using a #daily schedule from the BuildResultTrigger plugin.