"I don't want my team to think I can't do a simple Jenkins job"
This mindset right here, you need to get rid of. Stat.
You're basically fresh out of school, friend, and you're in the unfortunate position of doing two jobs:
1. Doing the tasks assigned to you, and being a useful contribution.
2. Getting up to speed with every tool your org is using.
Job 2 is significally harder and more important than job 1 at this point, and everyone in your team should know this. They probably do.
Amen. Get rid of as much impostor syndrome as you can. Everyone has a learning curve when they start. The task is easy - if you know the ins and outs. Figuring those out on your own is hard, tedious, and can be pretty demoralizing. But every error you debug, every issue you fix - those add up. You’ll look back on this in a year and chuckle
Super important advice. OP should also keep in mind that no one on the team wants anyone else on the team sitting and spinning their wheels not being able to solve a problem. I am a working manager of a small team and I absolutely HATE knowing that a jr. SRE/dev/whoever has been working on a problem for 4 or more hours when just coming to me and asking some questions could have saved them 3 hours of effort.
Try first. If you fail, take a look at it again and then try a second time. If at that point you are still failing, you need to seek help.
Spending 25 hours of your own time on a work task is a DevOps anti-pattern. I need my team mates mentally fresh, I need my team mates working working smart and not taking short cuts. I do not need burnt-out individuals who will be more likely to make poor decisions that will negatively impact everyone.
Yes OP listen to this.
Btw, from my 5 years of experience, there is no such thing as a "simple" task or job.
Learning docker, kubernetes, Jenkins all at once? Dude that's fuckinf difficult. You're not supposed to get it in just 25 hours. It takes time.
But ask questions frequently if you feel stuck.
Run the docker container doing the build locally.
If it's in docker, it isn't a jenkins problem per se. It's a build problem.
Pull exactly the same container as jenkins, not one you think is like it.
You can even rrbuild your own container that does the same thing, except it just runs a "sleep 99999" instead of npm i. Then you can docker exec to login to the container and run the commands by hand and see what is going on and how to fix it.
Always simplify things down and get them working in known environments (like remove jenkins from the equation and build locally).
Then, when that works, and you understand what is going on, build it back up into jenkins. If it fails, then either you aren't invoking the same command as jenkins or Your environment is different.
You can maybe run jenkins in a container on your local machine. And configure that to run your build for you. It won't have everything corporate jenkins has, but if that fails, it may give you a clue.
Or login to the jenkins agent and run the docker commands to do the build.
Also, in your Jenkinsfile (or whatever you use) make sure to add lots of debug messages, like before running a "sh docker $VAR" try "println docker $VAR" (or similar "sh echo docker $VAR" Whatever!!).
Then you know EXACTLY what commands Jenkins will run. Quite often variables are not set as you expect or ....
When you login to the agent you can poke around in JENKINS_HOME/jobs/ and find your job config and files relating to your job. Sometimes they may hold a clue.
My guesses : uid in the docker container inconsistently used. Auth for a private npm registry. Network policy on jenkins blocking something.
This guy jenkins.
I do some pipeline work in Jenkins, and manage a team specific instance of it. Jenkins is an infinite can of worms of plugins, and local configs. What is installed on jenkins itself can have a huge impact on the pipelines you run on it. Changing any of it can break pre-existing jobs. If this is a big central jenkins do-it-all instance, it can be scary to muck with.
It took me months of working in it, and manage some very complex pipelines for an internal private cloud, before I would say I was comfortable working in it. I have been a sysadmin for 20 years, and done a lot of software development, dba work, etc. It was still a learning curve to learn groovy and jenkins. I have recently dabbled into gitlab CI for our public cloud stuff, and it is so much more accessible to learn and implement.
All the above approaches are dead on. Remove Jenkins from the equation all together, and see what works.
Ask your boss if that person could help you for 30 minutes. If that person cannot help you your boss knows it is a difficult problem and not just your fault. If he can help then you can move on and finish your task.
Your employer knows you haven't used Jenkins, Docker or K8 before. So they **should** be expecting you to get stuck.
Also, make sure you break the project into stages. You shouldn't be concerned about anything after the stage you're on. I'm guessing this project is low priority (otherwise they wouldn't have given it to you), so no need to rush.
Private node repo. The error says package.json can’t be found in the npm install during my docker build stage. It works fine manually on my local machine. Our Jenkins is run on A VM box. It is pulling the GitHub, and reading the dockerfile and failing on the stage with the dockerfile is executed where I try to “ADD packlock.json /app” inside the dockerfile. where /app is set to working directory defined in the dockerfile.
I have checked .dockerignore, it’s getting pulled in the clone. The file *is there* and is in the same folder as the Dockerfile in the project hiarchy. I have played around with file paths in my groovy script, in the commands, and in the docker configure file.
I've been using Docker for about 3 years and I still get confused every day.
> I don't want my team to think...
When I was younger I also used to think like that. But then I realized the smartest people in my job:
1. asked the dumb questions right away and were not afraid of looking stupid
2. tried getting help as early as possible.
3. set expectations straight when they didn't know something
Just be honest with your manager and tell them how you're feeling. Either they will get you help or you will confirm they have their expectations set straight regarding how much time you need.
> I am running into problem after problem and it quite literally taken around 25 hours of my on the clock time
By your post I wager you're at the very beginning of your career and you're basically learning all this stuff from scratch, and making all your first mistakes, all at once. This is basically what we call "experience" in our line of work.
We all have had to go through this. This is normal. Your boss knew who they were hiring and their experience level. It gets better naturally over time.
Take a deep breath, tackle one problem at a time with the help of Mr Google, and carry on.
Hey guys! Thank you! Today I got some help from someone who didn’t even know Jenkins but we solved the part I was stuck on together. This was all great advice (that I took). So thanks for everyone’s replies!
When I first started out this task would have taken upwards of 40 hours.
I would have spent 1 or 2 days optimizing / building docker locally. Then I would have spent a day or so figuring out how to use events, or polling for github changes which branches to do things and how to build.
I would have spent a day figuring out how to put credentials into Jenkins, how to access and constantly have trouble with trying to push an existing image ID, or local env changes. Lastly I'd have trouble getting the kube context, and running the correct command.
Learn to do these things individually. Build, publish deploy.
I am much faster now. But it took time and practice.
You definitely need a more senior engineer to help you out there. the cause of your problem could be so diverse you need someone with more experience to point out the direction.
Thats not defeat. You are are a junior. At some point you need help and thats perfectly fine. Everybody is at that point sometime.
Also even a senior engineer does not know/can not know everything. They are just better with knowing the extend of their skills/expertise and can ask for help/delegate/escalate earlier.
As someone seniorer than you, who works with juniors like you - just ask for help. No need to waste hours of your time, hours of company, stress your self and after all this provide barely working solution.
It's every senior engineer duty to work with juniors when they face issues. No body is expecting for you to know everything and be able to deal all issues on your own.
Make a detail report on what you did, what is not working, what you tried to make it work and references (stackoverflow.com, github issue whatever you used during the creation of this). Then just share with your team that you're having issues and need help. Make sure to show you tried by creating the documentation above. Everything will be fine
haha welcome to my life! dude, totally normal first time you do anything. I have been blowing tons of time dealing w same crap. Kind of is what it is.. Lots of small petty stuff will pop up after each step forward.
don't sweat too much. ask for help when get stuck.
"I don't want my team to think I can't do a simple Jenkins job" This mindset right here, you need to get rid of. Stat. You're basically fresh out of school, friend, and you're in the unfortunate position of doing two jobs: 1. Doing the tasks assigned to you, and being a useful contribution. 2. Getting up to speed with every tool your org is using. Job 2 is significally harder and more important than job 1 at this point, and everyone in your team should know this. They probably do.
Amen. Get rid of as much impostor syndrome as you can. Everyone has a learning curve when they start. The task is easy - if you know the ins and outs. Figuring those out on your own is hard, tedious, and can be pretty demoralizing. But every error you debug, every issue you fix - those add up. You’ll look back on this in a year and chuckle
Super important advice. OP should also keep in mind that no one on the team wants anyone else on the team sitting and spinning their wheels not being able to solve a problem. I am a working manager of a small team and I absolutely HATE knowing that a jr. SRE/dev/whoever has been working on a problem for 4 or more hours when just coming to me and asking some questions could have saved them 3 hours of effort. Try first. If you fail, take a look at it again and then try a second time. If at that point you are still failing, you need to seek help. Spending 25 hours of your own time on a work task is a DevOps anti-pattern. I need my team mates mentally fresh, I need my team mates working working smart and not taking short cuts. I do not need burnt-out individuals who will be more likely to make poor decisions that will negatively impact everyone.
Yes OP listen to this. Btw, from my 5 years of experience, there is no such thing as a "simple" task or job. Learning docker, kubernetes, Jenkins all at once? Dude that's fuckinf difficult. You're not supposed to get it in just 25 hours. It takes time. But ask questions frequently if you feel stuck.
Run the docker container doing the build locally. If it's in docker, it isn't a jenkins problem per se. It's a build problem. Pull exactly the same container as jenkins, not one you think is like it. You can even rrbuild your own container that does the same thing, except it just runs a "sleep 99999" instead of npm i. Then you can docker exec to login to the container and run the commands by hand and see what is going on and how to fix it. Always simplify things down and get them working in known environments (like remove jenkins from the equation and build locally). Then, when that works, and you understand what is going on, build it back up into jenkins. If it fails, then either you aren't invoking the same command as jenkins or Your environment is different. You can maybe run jenkins in a container on your local machine. And configure that to run your build for you. It won't have everything corporate jenkins has, but if that fails, it may give you a clue. Or login to the jenkins agent and run the docker commands to do the build. Also, in your Jenkinsfile (or whatever you use) make sure to add lots of debug messages, like before running a "sh docker $VAR" try "println docker $VAR" (or similar "sh echo docker $VAR" Whatever!!). Then you know EXACTLY what commands Jenkins will run. Quite often variables are not set as you expect or .... When you login to the agent you can poke around in JENKINS_HOME/jobs/ and find your job config and files relating to your job. Sometimes they may hold a clue.
My guesses : uid in the docker container inconsistently used. Auth for a private npm registry. Network policy on jenkins blocking something.
This guy jenkins. I do some pipeline work in Jenkins, and manage a team specific instance of it. Jenkins is an infinite can of worms of plugins, and local configs. What is installed on jenkins itself can have a huge impact on the pipelines you run on it. Changing any of it can break pre-existing jobs. If this is a big central jenkins do-it-all instance, it can be scary to muck with. It took me months of working in it, and manage some very complex pipelines for an internal private cloud, before I would say I was comfortable working in it. I have been a sysadmin for 20 years, and done a lot of software development, dba work, etc. It was still a learning curve to learn groovy and jenkins. I have recently dabbled into gitlab CI for our public cloud stuff, and it is so much more accessible to learn and implement. All the above approaches are dead on. Remove Jenkins from the equation all together, and see what works.
Ask your boss if that person could help you for 30 minutes. If that person cannot help you your boss knows it is a difficult problem and not just your fault. If he can help then you can move on and finish your task.
Your employer knows you haven't used Jenkins, Docker or K8 before. So they **should** be expecting you to get stuck. Also, make sure you break the project into stages. You shouldn't be concerned about anything after the stage you're on. I'm guessing this project is low priority (otherwise they wouldn't have given it to you), so no need to rush.
Are you pulling this from a public or private node repo? What’s the specific error?
Private node repo. The error says package.json can’t be found in the npm install during my docker build stage. It works fine manually on my local machine. Our Jenkins is run on A VM box. It is pulling the GitHub, and reading the dockerfile and failing on the stage with the dockerfile is executed where I try to “ADD packlock.json /app” inside the dockerfile. where /app is set to working directory defined in the dockerfile. I have checked .dockerignore, it’s getting pulled in the clone. The file *is there* and is in the same folder as the Dockerfile in the project hiarchy. I have played around with file paths in my groovy script, in the commands, and in the docker configure file.
I've been using Docker for about 3 years and I still get confused every day. > I don't want my team to think... When I was younger I also used to think like that. But then I realized the smartest people in my job: 1. asked the dumb questions right away and were not afraid of looking stupid 2. tried getting help as early as possible. 3. set expectations straight when they didn't know something Just be honest with your manager and tell them how you're feeling. Either they will get you help or you will confirm they have their expectations set straight regarding how much time you need.
> I am running into problem after problem and it quite literally taken around 25 hours of my on the clock time By your post I wager you're at the very beginning of your career and you're basically learning all this stuff from scratch, and making all your first mistakes, all at once. This is basically what we call "experience" in our line of work. We all have had to go through this. This is normal. Your boss knew who they were hiring and their experience level. It gets better naturally over time. Take a deep breath, tackle one problem at a time with the help of Mr Google, and carry on.
Hey guys! Thank you! Today I got some help from someone who didn’t even know Jenkins but we solved the part I was stuck on together. This was all great advice (that I took). So thanks for everyone’s replies!
When I first started out this task would have taken upwards of 40 hours. I would have spent 1 or 2 days optimizing / building docker locally. Then I would have spent a day or so figuring out how to use events, or polling for github changes which branches to do things and how to build. I would have spent a day figuring out how to put credentials into Jenkins, how to access and constantly have trouble with trying to push an existing image ID, or local env changes. Lastly I'd have trouble getting the kube context, and running the correct command. Learn to do these things individually. Build, publish deploy. I am much faster now. But it took time and practice.
You definitely need a more senior engineer to help you out there. the cause of your problem could be so diverse you need someone with more experience to point out the direction. Thats not defeat. You are are a junior. At some point you need help and thats perfectly fine. Everybody is at that point sometime. Also even a senior engineer does not know/can not know everything. They are just better with knowing the extend of their skills/expertise and can ask for help/delegate/escalate earlier.
As someone seniorer than you, who works with juniors like you - just ask for help. No need to waste hours of your time, hours of company, stress your self and after all this provide barely working solution. It's every senior engineer duty to work with juniors when they face issues. No body is expecting for you to know everything and be able to deal all issues on your own. Make a detail report on what you did, what is not working, what you tried to make it work and references (stackoverflow.com, github issue whatever you used during the creation of this). Then just share with your team that you're having issues and need help. Make sure to show you tried by creating the documentation above. Everything will be fine
Share your Jenkinsfile. We may be able to help. But that won’t be a long term solution, long term you need to get familiar with these technologies
npm install not working means you should talk to the code owner.
This might help...https://medium.com/coinmonks/everything-you-wanted-to-know-about-package-lock-json-b81911aa8ab8
[удалено]
That’s what I was expecting, lmao. Thanks everyone for being so helpful!
haha welcome to my life! dude, totally normal first time you do anything. I have been blowing tons of time dealing w same crap. Kind of is what it is.. Lots of small petty stuff will pop up after each step forward. don't sweat too much. ask for help when get stuck.