I know how to create a TFS pull request using the web interface. However that is very inconvenient. From the command line already I am doing this
git checkout -b mybranch
git add <files>
git commit -m "my changes"
git push origin mybranch
so I want to type another thing such as
create-pull-request mybranch
instead of going to the browser and messing around with a different user interface. Perhaps I can do something with curl?
There is VSTS CLI interface that you can configure to use git aliases (see this article), including creating pull requests.
You could use VSTS CLI a new command line experience for managing VSTS/TFS resources.
The Create a pull request (example) command
vsts pr create --title "My PR" --auto-complete
Note： VSTS CLI is supported on Team Foundation Server 2017 update 2 and later.
Before getting started with this command, learn how to install the CLI here.
More details please refer this tutorial: Get started with the VSTS CLI
Related
Gerrit 2.13.8-4-gb79a18cfff-dirty
I just joined a new project.
Every time I push committed code to Gerrit I need to manually feed it a list of reviewers for my ticket/issue.
Is there any way I can save this list in Gerrit or does the owner of the project need to do that ( how? )
Thanks.
A solution would be to have the reviewers plugin installed/configured in your Gerrit server. Only the Gerrit administrators can do that.
See more info about Gerrit plugins here.
See more info about the reviewers plugin here.
Yes, you can set push options in your Git configuration to automatically add reviewers for every push. For example, to add john.doe as reviewer for every change pushed from this repository:
git config --local --add push.pushOption r=john.doe
The above approach requires Git 2.16+, though. See also Can I set push-options (git push -o “…”) in git config?.
If you are still on an older Git version locally, you could pass the option via a Bash or Git alias or even use the old syntax for push options, e.g.:
alias gpr 'git push origin HEAD:refs/for/master%r=john.doe'
I want to set in Jenkins jobs triggering Build after each commit
I dont have access to Setting in my repository on Github, so I don't have possibility using WebHook.
What is the best/.easy way to set this in other way?
I have jobs for private repository Github, and clone project by SSH
I also using Github Oauth Token
Jenkins Continuous Integration Server is on running on a Ubuntu host
You can use local git hook pre-push. It runs after you issue the "git push" command. (but executes before pushing)
See example: pre-push hook
I am completely new to Gitlab because previously I upload project to server using Filezilla. But now I have finished my Laravel projects in my local computer, and I would like to upload it to my could hosting. Currently my project is stored in c:\\xampp\htdocs\myproject.
Please tell me command line step-by-step to achieve this? I am using Putty on window. I can't understand it by reading existing tutorial.
I use DigitalOcean.com's server and yes I registered on gitlab.com to store/upload my project.
As a first approach, you can push directly to DigitalOcean, as describe in this tutorial:
clone your GitLab repo as a bare repo on your DigitalOcean instance (VPS: Virtual Private Server or Droplet)
cd
git clone --bare https://gitlab.com/<yourUsername>/<yourRepo.git>
add a post-receive hook similar to this auto-deploy article
That is:
cat > /home/rails/rails_project.git/hooks/post-receive
(Copy-paste the following lines)
#!/bin/sh
echo "-----------------------------------"
echo "Post receive hook: Updating website"
export GIT_WORK_TREE=/path/to/yourProject
export GIT_DIR=/home/yourUser/yourRepo.git
cd $GIT_WORK_TREE
git pull
git checkout master -f
(type Ctrl+D to exit)
Depending on your deployment path, you might have to execute the git commands as root, but it is best if you can keep your deployment as your username and not root.
But if you don't want to push to DigitalOcean, only to GitLab, you can use instead Git-Auto-Deploy.
Then you can push to GitLab, and that will trigger a deployment to your VPS.
When commits are pushed to your Git repository, the Git server will notify Git-Auto-Deploy by sending a HTTP POST request with a JSON body to a pre configured URL (your-host:8001).
The JSON body contains detailed information about the repository and what event that triggered the request.
Git-Auto-Deploy parses and validates the request, and if all goes well it issues a git pull.
Additionally, Git-Auto-Deploy can be configured to execute a shell command upon each successful git pull, which can be used to trigger custom build actions or test scripts.
I've just setup Jenkins and i have some Repositories in my Stash.
I installed the "Git plugin" in jenkins.
I can now enter the repository url but there is nothing to enter my credentials.
It's possible using
http://username:password#mydomain/xx/yy.git
but that is something i dont want to do.
What else can i do to authenticate?
I am the author of this stash plugin that might help you: https://github.com/palantir/stashbot
Taking selectively from the readme:
To work with Jenkins, you MUST install the following jenkins plugins first.
Jenkins GIT plugin
Post build task
Next, build and install the plugin using the plugin SDK (more details in the readme)
Next, the stash admin goes into the Stashbot Admin page and creates a jenkins server config - here you give it the URL, username/password, etc details of the jenkins server.
Next, for each repository a "Stashbot CI Admin" link shows up for repo admins. From there you can check the "enabled" checkbox and tell it what branches you want build (via a regex) and what command it should run to do the build (optionally verifies and publishes).
After this point, the remainder is completely self-service. Any repo admin can ask for their project to "have CI" by filling out that form, and the jobs will automatically be created in the jenkins server.
Hope that helps.
Set up an SSH key for the user that runs your Jenkins builds and add it to the repository's SSH keys in Stash. See the Stash docs for instructions.
Two things to add to Gareth's answer.
While I agree that using SSH keys are definitely better than hard-coding the username/password, it's worth mentioning that Stash (currently) scales better with HTTP when it comes to CI. If you have quite a few builds we generally recommend using HTTP. We are currently extending our Git cache support to support SSH so this no longer an issue.
Somewhat related, you might be interested in watching and voting for the following feature which will make it easier to create CI specific keys.
Lastly having build icons show up in Stash is surprisingly handy, and you should have a look at the following plugin if you haven't already:
https://github.com/jenkinsci/stashNotifier-plugin
Since version 2.0 of "Git Plugin" for jenkins you should be able to directly add the required credentials for both ssh and username/password (based on credentials plugin).
See changelog of Git plugin: https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin#GitPlugin-Changelog for details.
For further integration of git and stash regarding pull requests you additionally need the "Stash Webhook for jenkins" add-on in stash and the "Stash Notifier" plugin for jenkins to connect each other.
I am trying to learn github to deploy a webpage. Here are the steps I am taking:
git checkout master
git pull origin master
git checkout –b my-awesome-branch
Do some work, do a git status to check on everything, everything is ok.
git add .
git commit –m "awesome message here"
git push origin my-awesome-branch
git checkout integration
git merge my-awesome-branch
git push origin integration
cap development deploy
this will push a file to the dev server we have so people can look at it - this worked fine for me you won't be able to see the link but it generates something like this:
http://dev.mywebsite.com/events/email/welcome
Let's go live (pretending there are no further changes)
git checkout master
git merge my-awesome-branch
git push origin master
cap production deploy
In theory, the file should push to the live website (which would be http://mywebsite.com/events/email/welcome) but that webpage is not created when i cap production deploy.
Another developer more familiar with this system says :
It looks like you forked "my party events" repo and have pushed the
master there. You'll want to push master to the upstream remote (the
main "my party events", or my_events repo.)
I don't follow this step. Can anyone follow this logic? If so, do you have a suggestion for me on what i may be doing wrong? Any help is appreciated.
If you have a forked branch on Github, that means you have a copy of the entire git repo under your name. Check your Github account to verify this.
To do this, go to https://github.com/your-github-user-name-here. On the left side, look for "my-party-events" (assuming that's the repo name). Underneath it, look for "forked from xyz/my-party-events".
If you don't see 'forked from ...', then you're the original owner of that repo. This shouldn't be the case.
If you do see 'forked from ...', then you have a copy under your name (that's what a fork is). Any changes you make to a fork don't affect the original repo.
If you're with me up to here, there's 2 ways you can go.
Via Git (Recommended)
Whenever you did a git pull or git push earlier, you were specifying origin, which is a human-readable name for a repo that you set up earlier. The repo address actually looks like this
git#github.com:your-user-name/project-name.git
As you can see, referring to it by a nickname like 'origin' is way easier to remember.
Assuming you have write access to the main project repo, you can just add another repo to your config. Make sure you have write access before attempting this, otherwise you're just wasting your time. Ask your coworker if you're not sure.
Lets say you wanted to nickname the repo as 'production', you would do this
git remote add production git#github.com:PROJECT_OWNER/project-name.git
The git repo address looks almost identical to your fork repo. It differs only by username. On the front page of all Github projects, the repo address is in a text field. It's next to the "SSH | HTTPS | Git Read-only" buttons. Get the address from there, replace it in the command above, and finally, do this in your command line
git push production master
From now on, you can just git push production master, which is pretty simple. If you don't have write access, then you'll have to submit changes via pull requests.
Through the Website
You can submit a pull request to the repo you forked from. A pull request asks the original repo admin to include changes you've made on your fork.
To submit a pull request, click on your project fork from your projects page. Look for the 'Pull Request' icon near the top right. That should take you to a page where you can choose the target and source branches.