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
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?
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
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
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" }
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
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.
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
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..
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.
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.
@@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.
@@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.
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.
![[#2024MAMA] ROSÉ (로제), Bruno Mars - APT. | Mnet 241122 방송](http://i.ytimg.com/vi/dgGqD28J6aQ/mqdefault.jpg)
Very nice explanation. Tysm!
how you explained this was so easy to understand it!!!! thanks!
This is really awesome ,
Can you please tell me if we can store github secrets into the file at the run time
This is exactly what I needed and a total pain without your vid. Thanks man, subbed!
🎉
Thanks a lot Mickey, this is what something I was searching for
Good stuff. For completeness, it would have been nice to illustrate how to access environment secrets from steps.
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
why not do this at the workflow scope, or at least allow us to specify multiple environments per job? @@MickeyGousset
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?
This is awesome! Very much needed, and excellent implementation. :)
Thanks for watching and for the feedback!
Good one. Plese keep doing more on this
Love it! Hope you could share more on GitHub actions.
the repo for the yaml file seems to be gone
I cannot see the environments option in Settings tab. where can I access it ?
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
Excellent tutorial! Thank you for this.
Thank you!
where can I find this script please?
can environments be created and set using yml rather than doing manually?
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
Hey how does GitHub actions knows the environment details like the hostname ? Ip address?
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
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"
}
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
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.
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
Multiple jobs can point to the same environment. But a job can only point to one environment at a time
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..
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.
Earned yourself a sub. Thanks for the content.
Awesome, thank you!
Thanks! I learned something new!
Thanks for watching!
Perfectly explained :)
Thanks for the video
Thanks for watching and commenting!
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?
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.
@@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.
@@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.
This is gold
Great video, thanks :)
you are awesome! upload more vids
SUPERB!
finally i got the solution thanks lot
Thanks man
so where are the environments? where have you used those envs that you created? how to use it?
that MY_SECRET you'd created.
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.
required reviewers only available to enterprise plan, such a shame for this so basic feature
They are available for public eepos
Without an enterprise plan
Shouldn’t have given same names to envs and jobs, makes it more confusing 😅
Good feedback thank you. I’m planning to update the video I’ll take that into consideration
@@MickeyGousset the video is great nevertheless, thanks!
Thank you :)