mvn command is not recognized as an internal or external command build step 'invoke top-level maven targets' marked build as failure jenkins

On my Windows 7 machine I have the following environment variables:

• JAVA_HOME=C:\Program Files\Java\jdk1.7.0_07
• M2_HOME=C:\apache-maven-3.0.3

On my PATH variable, I have (among others) the following:

• %JAVA_HOME%\bin;%M2_HOME%\bin

I tried doing what you've done with %M2% having the nested %M2_HOME% and it also works.

NOTE:

on your jenkins go to Jenkins Dashboard

Manage jenkins  -----> Manage Jenkins ----> Global tool configueration ---> add PATH for JAVA_HOME and MAVEN_HOME.

Jenkins Github Authentication error: user is missing the Overall/Read permission

Task:

Access Denied

<user> is missing the Overall/Read permission

Solution:

This is how I resolved the authentication problem:

1.  Edit config.xml file, e.g.

2.  sudo vi /var/lib/jenkins/config.xml

1.  Change useSecurity element's value to false, e.g.

2.  <useSecurity>false</useSecurity>

3.  Remove authorizationStrategy block

3.  Restart Jenkins: /etc/init.d/jenkins restart.

4.  Access Jenkins through URL as usual and reconfigure security again.

Scheduling tasks in Jenkins

To schedule a cron job every 5mins you need to define the cron settings like this: */5 * * * *

*/5 * * * * means every 5 minutes

5 * * * * means the 5th minute of every hour

 

Jenkins lets you set up multiple times, separated by line breaks.  If you need it to build daily at 7am, along with every Sunday at 4pm, the below works well  H 7 * * * H 16 * * 0   use */5 * * * * for every 5mins   By setting the schedule period to 15 13 * * * you tell jenkins to schedule the build every day of every month of every year at the 15th minute of the 13th hour of the day. What Jenkins used is a cron expression, the different fields are : 1.  MINUTES Minutes in one hour (0-59) 2.  HOURS   Hours in one day (0-23) 3.  DAYMONTH    Day in a month (1-31) 4.  MONTH   Month in a year (1-12) 5.  DAYWEEK Day of the week (0-7) where 0 and 7 are sunday If you want to shedule your build every 5 minutes, this will do the job : */5 * * * * If you want to shedule your build every day at 8h00, this will do the job : 0 8 * * *  To allow periodically scheduled tasks to produce even load on the system, the symbol H (for “hash”) should be used wherever possible. For example, using 0 0 * * * for a dozen daily jobs will cause a large spike at midnight. In contrast, using H H * * * would still execute each job once a day, but not all at the same time, better using limited resources. Note also that : The H symbol can be thought of as a random value over a range, but it actually is a hash of the job name, not a random function, so that the value remains stable for any given project

 

GitHub

Let’s get started with GitHub!

You’ll learn how to:

• Create and use a repository
• Start and manage a new branch
• Make changes to a file and push them to GitHub as commits
• Open and merge a pull request

What is GitHub?

GitHub is a code hosting platform for version control and collaboration. It lets you and others work together on projects from anywhere.

This tutorial teaches you GitHub essentials like repositories, branches, commits, and Pull Requests. You’ll create your own Hello World repository and learn GitHub’s Pull Request workflow, a popular way to create and review code.

No coding necessary

To complete this tutorial, you need a GitHub.com account and Internet access. You don’t need to know how to code, use the command line, or install Git (the version control software GitHub is built on).

Tip: Open this guide in a separate browser window (or tab) so you can see it while you complete the steps in the tutorial.

Step 1. Create a Repository

A repository is usually used to organize a single project. Repositories can contain folders and files, images, videos, spreadsheets, and data sets – anything your project needs. We recommend including a README, or a file with information about your project. GitHub makes it easy to add one at the same time you create your new repository. It also offers other common options such as a license file.

Your hello-world repository can be a place where you store ideas, resources, or even share and discuss things with others.

To create a new repository

1. In the upper right corner, next to your avatar or identicon, click  and then select New repository.
2. Name your repository hello-world.
3. Write a short description.
4. Select Initialize this repository with a README.

Click Create repository. 

Step 2. Create a Branch

Branching is the way to work on different versions of a repository at one time.

By default your repository has one branch named master which is considered to be the definitive branch. We use branches to experiment and make edits before committing them to master.

When you create a branch off the master branch, you’re making a copy, or snapshot, of master as it was at that point in time. If someone else made changes to the master branch while you were working on your branch, you could pull in those updates.

This diagram shows:

• The master branch
• A new branch called feature (because we’re doing ‘feature work’ on this branch)
• The journey that feature takes before it’s merged into master

Have you ever saved different versions of a file? Something like:

• story.txt
• story-joe-edit.txt
• story-joe-edit-reviewed.txt

Branches accomplish similar goals in GitHub repositories.

Here at GitHub, our developers, writers, and designers use branches for keeping bug fixes and feature work separate from our master (production) branch. When a change is ready, they merge their branch into master.

To create a new branch

1. Go to your new repository hello-world.
2. Click the drop down at the top of the file list that says branch: master.
3. Type a branch name, readme-edits, into the new branch text box.
4. Select the blue Create branch box or hit “Enter” on your keyboard.

Now you have two branches, master and readme-edits. They look exactly the same, but not for long! Next we’ll add our changes to the new branch.

Step 3. Make and commit changes

Bravo! Now, you’re on the code view for your readme-edits branch, which is a copy of master. Let’s make some edits.

On GitHub, saved changes are called commits. Each commit has an associatedcommit message, which is a description explaining why a particular change was made. Commit messages capture the history of your changes, so other contributors can understand what you’ve done and why.

Make and commit changes

1. Click the README.md file.
2. Click the  pencil icon in the upper right corner of the file view to edit.
3. In the editor, write a bit about yourself.
4. Write a commit message that describes your changes.
5. Click Commit changes button.

These changes will be made to just the README file on your readme-editsbranch, so now this branch contains content that’s different from master.

Step 4. Open a Pull Request

Nice edits! Now that you have changes in a branch off of master, you can open a pull request.

Pull Requests are the heart of collaboration on GitHub. When you open a pull request, you’re proposing your changes and requesting that someone review and pull in your contribution and merge them into their branch. Pull requests showdiffs, or differences, of the content from both branches. The changes, additions, and subtractions are shown in green and red.

As soon as you make a commit, you can open a pull request and start a discussion, even before the code is finished.

By using GitHub’s @mention system in your pull request message, you can ask for feedback from specific people or teams, whether they’re down the hall or 10 time zones away.

You can even open pull requests in your own repository and merge them yourself. It’s a great way to learn the GitHub Flow before working on larger projects.

Open a Pull Request for changes to the README

Click on the image for a larger version

Step	Screenshot
Click the  Pull Request tab, then from the Pull Request page, click the green New pull request button.
Select the branch you made,readme-edits, to compare with master (the original).
Look over your changes in the diffs on the Compare page, make sure they’re what you want to submit.
When you’re satisfied that these are the changes you want to submit, click the big green Create Pull Requestbutton.
Give your pull request a title and write a brief description of your changes.

When you’re done with your message, click Create pull request!

---

Tip: You can use emoji and drag and drop images and gifs onto comments and Pull Requests.

Step 5. Merge your Pull Request

In this final step, it’s time to bring your changes together – merging yourreadme-edits branch into the master branch.

1. Click the green Merge pull request button to merge the changes intomaster.
2. Click Confirm merge.
3. Go ahead and delete the branch, since its changes have been incorporated, with the Delete branch button in the purple box.

Git: Show current branch name only

While git branch will show you all branches and highlight the current one with an asterisk, it can be too cumbersome when working with lots of branches.

To show only the branch you are currently on, use:

git rev-parse --abbrev-ref HEAD

Git: Force a rejected push

If you modified git's history and the change was already pushed, you will usually get a
! [rejected] my-branch -> my-branch (non-fast-forward)
error, when trying to push.

You can force the push, with
git push –force origin my-branch

Careful:

• You might lose history.
• Unless your git is configured to push only the current branch, you must supply the remote branch name or you will force-pushall your branches!
• Anyone else who has already pulled the changes will run into significant trouble.

Only do this to instantly fix a mistake, or when you know exactly what you're doing.

Git: Delete a branch (local or remote)

To delete a local branch

git branch -d the_local_branch

To remove a remote branch (if you know what you are doing!)

git push origin :the_remote_branch

Note

If you get the error error: unable to push to unqualified destination: the_remote_branch The destination refspec neither matches an existing ref on the remote nor begins with refs/, and we are unable to guess a prefix based on the source ref. error: failed to push some refs to 'git@repository_name'

perhaps someone else has already deleted the branch. Try to synchronize your branch list with

git fetch -p 

The git manual says -p, --prune After fetching, remove any remote-tracking branches which no longer exist on the remote.

Ansible interview questions and answers

http://interviewquestionsanswerspdf.com/2016/07/ansible-interview-questions-answers/

Docker interview questions and answers

http://interviewquestionsanswerspdf.com/2016/07/docker-interview-questions-answers/

Chef interview questions and answers

http://interviewquestionsanswerspdf.com/2014/04/chef-interview-questions-and-answers/

Puppet interview questions and answers

http://interviewquestionsanswerspdf.com/2016/07/puppet-interview-questions-answers/

SVN(subversion) interview questions and answers

http://interviewquestionsanswerspdf.com/2016/08/svn-interview-questions-answers-subversion/

JENKIN interview questions and answers

http://interviewquestionsanswerspdf.com/2016/07/jenkin-interview-questions-answers/

GIT interview questions and answers
http://interviewquestionsanswerspdf.com/2014/06/git-interview-questions-and-answers/

Devops interview questions and answers

http://interviewquestionsanswerspdf.com/2016/07/devops-interview-questions-answers/

A career shift to DevOps

Here are a few things you should do to begin positioning yourself as a DevOps engineer.

• Interview at a company that's hiring DevOps. If you get hired, you'll learn the operations side of things fast. Real fast. Or get fired. If you don't get hired, you'll learn what is still missing from your resume / experience that's preventing you from becoming a full-time DevOps engineer. Incidentally, we're hiring: Keep Austin Bazaar

• Tell your boss you want to become a DevOps engineer at your company. Your boss should help you to this end. If he/she does not, quit. Then come work at Bazaarvoice with me and a bunch of other really awesome, super talented engineers working on some really awesome and challenging problems.

• Obtain practical experience by using your skills as a software engineer to build tools rather than software. Look at any of the open source projects Netflix has written for examples / ideas.

• Learn OpenStack. You can do this on your own time and budget. It's not important whether OpenStack sucks compared to Rackspace Cloud. What's important is that you understand all of the various components and why they are important. Have a wad of cash lying around? Learn Amazon Web Services instead.

• Participate in anything your team does involving operations -- deployment, scale, etc. (See list above: "What DevOps is.") If your team doesn't do any of that (i.e., they send artifacts over to Operations and the Operations team does deployment), go over to the perations team and sit in on a few deployments.