This is exactly what I needed and a total pain without your vid. Thanks man, subbed!
@victoriarussell37612 күн бұрын
🎉
@javierrenteria31952 жыл бұрын
how you explained this was so easy to understand it!!!! thanks!
@sundeepkumarpaulraj83813 жыл бұрын
Thanks a lot Mickey, this is what something I was searching for
@jimblizzard28063 жыл бұрын
This is awesome! Very much needed, and excellent implementation. :)
@MickeyGousset3 жыл бұрын
Thanks for watching and for the feedback!
@d0nhect0r2 жыл бұрын
Good stuff. For completeness, it would have been nice to illustrate how to access environment secrets from steps.
@MickeyGousset2 жыл бұрын
Thank you for the feedback. You access them just like you do any other secret: ${{secrets.MY_SECRET_NAME_HERE}}. The catch is, you will only be able to access the environment secret if the job is targeting that environment
@wkhatch10 ай бұрын
why not do this at the workflow scope, or at least allow us to specify multiple environments per job? @@MickeyGousset
@jaswanth_kumar_k Жыл бұрын
Good one. Plese keep doing more on this
@akilanorton933115 күн бұрын
I cannot see the environments option in Settings tab. where can I access it ?
@MickeyGousset15 күн бұрын
Are you looking at the repo settings? Are you a repo admin? Is actions turned on? If all the above are true, then you should see it under the repository settings
@redmizaki58383 жыл бұрын
Love it! Hope you could share more on GitHub actions.
@wkhatch10 ай бұрын
So, am I understanding this correctly that I need to associate an environment with a job, one and only one, per job, so, I'll now need to redefine the same job n number of times of n environments, just so I can reference a different value for a secret with the same key, which is the problem I was trying to avoid in the first place? This seems ugly, and I feel I must be missing something
@MickeyGousset10 ай бұрын
Multiple jobs can point to the same environment. But a job can only point to one environment at a time
@sumangeorge74 ай бұрын
can environments be created and set using yml rather than doing manually?
@MickeyGousset4 ай бұрын
If you add the environment to your job and it doesn’t exist then it will create it. But you can’t configure the environment from YAMl
@jyotireddy3419 ай бұрын
where can I find this script please?
@Kumar34761Ай бұрын
Hey how does GitHub actions knows the environment details like the hostname ? Ip address?
@MickeyGoussetАй бұрын
It doesn’t. Environments in Actions is just a construct for things like approving the job before it runs and for secrets and variables available to that job. So you could create a secret or variable for host name or ip address and then it can be used by the job that is targeting that environment
@umesh10569 ай бұрын
This is really awesome , Can you please tell me if we can store github secrets into the file at the run time
@nirmalkumar54059 ай бұрын
you are awesome! upload more vids
@michaelsainz52943 жыл бұрын
Thanks! I learned something new!
@MickeyGousset3 жыл бұрын
Thanks for watching!
@g-luu2 жыл бұрын
Earned yourself a sub. Thanks for the content.
@MickeyGousset2 жыл бұрын
Awesome, thank you!
@hemanthshankar45203 жыл бұрын
Thanks for the video
@MickeyGousset3 жыл бұрын
Thanks for watching and commenting!
@vikramragunathan63922 жыл бұрын
Perfectly explained :)
@andresgutierrez39653 жыл бұрын
This is gold
@JustinHonda-r2z7 ай бұрын
SUPERB!
@vinodhkumar3777 Жыл бұрын
finally i got the solution thanks lot
@danielt5542 Жыл бұрын
I got one question. In a real world project what conditions needs to be met in order to move from DEV to QA and then PROD, unit testing?
@MickeyGousset Жыл бұрын
Unfortunately the classic answer is "it depends". It is really going to depend on what your process is for being able to move from one environment to another. Unit testing, in my opinion, is something that must pass BEFORE you even push to the main branch, so it needs to occur during the pull request. Now it should also occur again any time you are doing a build, so, for example, if you are deploying to your DEV environment every time there is a push to main, you want to include unit testing in the build, to make sure everything is OK. Now, as far as what needs to be met to go from DEV to QA to PROD, it really depends on the organization and the process. Some customers I have worked with have a 24 hour wait period before they can move from one environment to the next. And if you have a QA env before a PROD one, then i'm sure there are manual or automated tests that also need to pass before you would want to move into PROD. This would make a good question/discussion on the GitHub subreddit.
@danielt5542 Жыл бұрын
@@MickeyGoussetyeah, i am actually starting with a project where i already define my ci/cd pipeline to deploy a docker image into kubernetes and one requirement is to create a dev, qa and prod environment. I think i will have to research what kind of tests needs to be addressed between QA and prod, because if I am already covering what i think is more important in my CI/CD, i am not sure what needs to be tested in those environments. Thanks mickey, this is a really wonderful topic to cover.
@MickeyGousset Жыл бұрын
@@danielt5542 usually the testing from QA to PROD is whatever you need to do to make yourself feel confident that you can deploy the code, and is usually a mixture of manual and automated tests. That said, if you want to send me an email at mickeygousset@github.com, with some details of what you are deploying and any other information you might find relevant, I'll throw it at some people on my team who know way more than I do about containers and K8S and see how they might answer the question.
@ssahillppatell3 жыл бұрын
Thanks man
@piyush_dolar Жыл бұрын
so where are the environments? where have you used those envs that you created? how to use it? that MY_SECRET you'd created.
@MickeyGousset Жыл бұрын
The environments are created at the repository level. You can see the use of environments at the job step, there is a keyword "environment" which then specifies the environment you are pointing the job at.
@ohyesthelion4 ай бұрын
Shouldn’t have given same names to envs and jobs, makes it more confusing 😅
@MickeyGousset4 ай бұрын
Good feedback thank you. I’m planning to update the video I’ll take that into consideration
@ohyesthelion4 ай бұрын
@@MickeyGousset the video is great nevertheless, thanks!
@JotafrogАй бұрын
Thank you :)
@HeavyMikArmor5 ай бұрын
Hi! Thank you for the concise explanation. I would like to ask clarifications about the differences between environments' secrets and deploy keys. Can we say that a deploy key is used more as a (public ssh) key to identify your server (and thus perform deployment), and that it's related to the whole repository, whereas an environment secret should be used for credentials like cloud services and that is scoped within environment defined branches? Even this way, why should one store a ssh key as a deploy key rather than an environment secret, since the latter has more options?
@WildLifeBackyardCamera8 ай бұрын
required reviewers only available to enterprise plan, such a shame for this so basic feature
@MickeyGousset8 ай бұрын
They are available for public eepos
@MickeyGousset8 ай бұрын
Without an enterprise plan
@Southpaw07 Жыл бұрын
This is great tutorial, i was wondering if I can setup similar workflow that uses env variable = dev and prod in terraform code to run on a particular deployment branch Dev or Main (prod) in GitHub based of the env variables in TF code as an example variable "vmname" { default = { dev = "devcorpvm" prod = "prodcorpvm" }
@ankusnayak7005 Жыл бұрын
Sir, i have a question regards this thing ..if any job failed to run then dependent job stops there. But what if jobs are ok (working fine) but deployment in env generates some error then how to handle that thing ? I have tried, but while deployment gets error still jobs are passed how to handle that case ? Thanks in advance..
@MickeyGousset Жыл бұрын
I think you would need to check, in the job that is doing the deployment, that everything is ok. If it isn't, then you could have a step that just does an "exit 1", which will cause the step and the job to fail, and can fail the future jobs.
@hashemalrifai2 жыл бұрын
Great video, thanks :)
@adi_sekar2 жыл бұрын
Thank you, exactly what I needed. Do you recommend having multiple branches to reflect this? Or just go off a main. What is best branching strategy for an actual production app
@MickeyGousset Жыл бұрын
That is a tricky question, which falls into your process. Some people like GitFlow, I'm more of a GitHubFlow type of person, because it does trunk based development in a way that I like.