I am planning to store some of the key/values inside GitLab CI/CD variables? I found in the document that each value is limited to 1000 characters. I am wondering if there is any limitation for the number of keys/values as well?
For the default plan the limit of variables in self hosted instance would be 25 according to https://docs.gitlab.com/ee/administration/instance_limits.html#number-of-instance-level-variables
But it states that you can update this number
You can now see all limits for CI/CD with See GitLab 15.0 (May 2022):
Show instance CI/CD limits in /help
Instance Administrators can set a number of CI/CD limits in the Admin Area of their instance. It is hard for users without administrator access to know what the limits are, especially when pipelines are failing because they bump into limits they didn’t know existed.
Now the CI/CD related limits for the instance can be seen on the instance configuration page found at /help/instance_configuration.
Thanks to #wwwjon for this contribution!
See Documentation and Issue.
GitLab 15.7 (Dec. 2022) brings a precise answer:
Limit the number of project or group CI/CD variables to 200
If your instance has project or group maintainers adding too many CI/CD variables, it could use a lot of resources to process all the variables for each pipeline.
To ensure your pipelines continue to run efficiently, we have added a limit of 200 variables per group or project.
Projects and groups that already have over 200 CI/CD variables can continue to run pipelines as before, but will not be able to add any more variables.
We recommend reducing the number of CI/CD variables down to less than 200 per group or project for optimal performance.
See Documentation and Issue.
It would be 25 according to the default plan but you can change it. Hope that answers your question!
https://docs.gitlab.com/ee/administration/instance_limits.html#number-of-instance-level-variables
Well, I see now that Tolis already clarified it but I will still post this :)
Related
For about 18 months now I've been working in Node; and for the last 6 months I've been slowly migrating my existing WordPress websites to NextJS.
To date, I've been deploying to production manually. I log into my production server, checkout the latest release from GitHub, build, and do a pm2 restart.
Even though the above workflow seems to be the most commonly documented around the internet, it's always felt a little wrong to me.
Recently, I found myself in a situation where I needed to customise some 3rd party code. So, my main code now has a line in package.json that says
{
...
"dependencies": {
...
"react-share": "file:../react-share/react-share-4.4.1.tgz",
...
},
...
}
which implies that I'm going to checkout my custom react-share, build it somewhere on the production server, change this line to point to wherever I put it, and then rebuild.
Also, I'm using Prisma, which means that every time I deploy, before I do a build, I need to do an npx prisma generate to create the client.
This now all seems really, really wrong.
I don't know how a "simple" CI/CD environment might look, but whatever it looks like, it feels like overkill. It's just me doing development, and my production environment is a single EC2 server sitting behind AWS CloudFront.
It seems to me that I should be doing something more/different than what I'm currently doing, in service to someday moving to a CI/CD model, if/when I have a whole team working on this, or sufficient users that I have multiple load-balanced servers and need production to be continually up.
In particular, it feels like I shouldn't be building on the production server.
Are there any intermediary step(s) I can/should be taking for faster/less-error-prone/less-down-time deployment to a single EC2 instance for Next/Node apps, between manually deploying as I am currently, and some sort of CI/CD setup? Or are my only choices to do what I'm doing now, or go research how to do CI/CD?
You're approaching towards your initial stages of what technically is called DevOps, if not already as it appears from your context. What you're asking is a broad topic, which is an understatement, and explaining each and everything here will almost be like writing an article about it, at the very least.
However, I'll brief you overall on how to approach with this.
I don't know how a "simple" CI/CD environment might look, but whatever it looks like, it feels like overkill.
Simplicity & complexity are relative terms. A system which is complicated for one might be simple for another. CI/CD doesn't define any laws that you need to follow in order to create a perfect deployment procedure, as everyone's deployment requirement is unique (at some point).
If I mention it in bullet points, what you need to figure out before you start with setting up CI&CD, is -
The sequence of steps your deployment procedure needs in order to deploy your latest version. As you have stated already that you've been doing deployment manually, that means you already know your steps. All you need to do is to fine-tune each step so that it shouldn't require manual intervention while being executed automatically by the CI program.
Choose a CI program, like Travis CI, Circle CI, or if you're using GitHub, it has it's own GitHub Actions for the purpose, you can read their documentation for more details. Your CI program will be responsible for executing your deployment steps which you'll mention to it in whichever format it understands (mostly .yml).
The CI program will execute your steps on behalf of you based on the condition which you'll provide, (like when code is pushed on prod branch). It will execute the commands on a machine (like your EC2), specifically, GitHub actions runner will be responsible for running your commands on your machine, the runner should be setup beforehand in the instance you intend to deploy your code on. More details on runners can be found in relevant documentations.
Since the runner will actually execute the commands on your machine, make sure that all required commands and parameters, including the concerned files & directories are accessible to the runner program, from permissions point of view at least. For example, running your npx prisma generate command should require that npx command is available and executable in the system, and the concerned folders in which the command will CRUD files is accessible by the runner program. Similarly for all other commands.
Get your hands on bash scripting as well.
If your steps contain dynamic info, like the one you mentioned that in your package.json an npm script needs to be updated, then a custom bash script created to update the same automatically will help, for instance. There will be however, several other ways depending on the specific nature of the dynamic changes.
The above points are huge (by huge, I mean astronomically huge) oversimplification of the ways through which CI&CD pipelines are setup. But I hope you get the idea of it at least.
In particular, it feels like I shouldn't be building on the production server.
Your feeling is legitimate. You should replicate your production environment (including deployment procedures) into a separate development environment as close as possible, in order to have all your experiments, development and testing done separately from production environment, and after successful evaluation on the development environment, deploy on production one. Steps like building will most likely be done on both environments, as it is something your program needs to run, irrespective of the environment it is running in. Your future team will appreciate this separation of environments.
if/when I have a whole team working on this, or sufficient users that I have multiple load-balanced servers and need production to be continually up.
Again, this small statement in itself is a proper domain of IT department, known as System Design, in which, to put it simply, you or your team will create an architecture for your whole system which will support your business requirements and scaling as your audience increases, which is something a simple Stackoverflow QnA won't suffice to explain.
Therefore,
or go research how to do CI/CD?
is what I'd recommend and you should also feel is the right way ahead, after reading everything above.
Useful references to begin with (not endorsing any resources, you can search for relevant/better resources too)
GitHub Actions self-hosted runners
System Design - Getting started
Bash scripting
Development, Staging, Production
GitLab supports a variety of Push Options. Is there any way to check, in the web user interface or otherwise, what push options were used in a pipeline or job? In particular, what ci.variable push options are associated with the job or pipeline?
One workaround is to run env with every job, but it seems like this information might already be available in the user interface.
Git hooks
The only definitive way to know exactly what git push options were used is in a pre-receive or post-receive git hook or looking at server logs. This is only possible on a self-managed GitLab instance.
In these hooks, the GIT_PUSH_OPTION_COUNT tells you how many push options were used. The variables GIT_PUSH_OPTION_<i> contain each option. So you could configure a hook that inspects these variables to know which options were used.
Getting pipeline variables using the API
If you just need to know what variables were used for creating the pipeline and don't care about the source, that can be done with the pipelines API.
This will include variables for the pipeline added by git push options, but does not distinguish between variables added by git push options or other sources and won't contain variables added at the job level or dynamically.
curl --header "PRIVATE-TOKEN: <your_access_token>" \
"https://gitlab.example.com/api/v4/projects/1/pipelines/46/variables"
Also keep in mind the caveat that it's possible for variables to change mid-pipeline. So, this may not be adequate if you must be 100% assured of the environment for every job at every stage in the pipeline.
Runtime introspection likely insufficient for differentiation
If the goal is to determine, specifically, which variables were added by git push options (and not any other sources), doing this at runtime may be difficult to do with 100% certainty.
By the time a pipeline has been evaluated and the job is running, environment variable configurations could have changed and you can't be 100% certain of the source of a variable. You may be able to guess in some circumstances by introspecting the environment, pipeline configuration file, project and group CI/CD configurations, etc. But there will likely be gaps due to permission and other issues.
Some obstacles that will be difficult or impossible to overcome to determine variable source from introspection:
You may not have permission to inspect ancestor group or instance level variables
If you use self-hosted runners, variables can be configured on the runners
Variables can come from the image: used.
Variables can be set dynamically by triggers or artifacts
Variable configurations may change after the pipeline/job are started
In other words, you may not know if a new variable comes from a git push option or a change in any of these other things you can't inspect at runtime.
One workaround is to run env with every job
That would give you 100% certainty of the environment for each job. But still you would not know which ones came from the push options, as opposed to other sources, as mentioned above.
You could also artifact the environment and retrieve that artifact programmatically, but you may risk placing sensitive information in your artifacts, so that's probably not a good idea on its own, unless you're very careful to exclude them.
You could enable debug logging but that also has security risks.
Essentially, I have, say, 10 Pipelines that all run at the same time on 3 available Agents. So only 3 run at a time, and the rest are queued. I need each pipeline to have a variable that I can use for the entire pipeline, but I need that variable to be chosen from a specific list. Furthermore, I would like the variable that is chosen, to not be able to be chosen by another pipeline while it is being used by one. Once that Pipeline is finished, that variable can then be used again by a different Pipeline. So I would like each Pipeline to choose from a list of available options and set one of those options as a Pipeline variable, then free up that option for a later running Pipeline to be able to choose it again. Is this possible?
No, this cannot be accomplished. With YAML pipelines you can specify parameters and possible values, but your desired locking requirements can't be added.
Simple, but unfortunate answer.
If what you're trying to do is make sure pipelines aren't accessing the same environments or resources, then you may want to look into the 'Environments' and deployment stages. With policies on the environment or specific environment resources, you can prevent 2 pipelines from attempting to access the same environment or the same resource in an environment at the same time.
There is no queue-time block, the pipeline will just wait its turn.
I have a gitlab repository where I have different variables assigned to different environments. I have a pipeline for this repository which I would like to be deployed to those different environments.
I don't want to code the environment directly in my code so I would like to choose the environment manually as the first stage of my pipeline so that the pipeline only use those variables assigned to the chosen environment since then.
Is this possible in gitlab? Has it any sense?
You could probably use dynamic child-pipeline to create a "blank" template of your deployments that will be serialized using your variables during your main pipeline. This way you could have cleanly separated jobs for each environnements.
I hope this help or at least gives some clues about the right way to do it, have fun!
We use the commit branch name for which the pipeline is running for to declare our environments.
environment:
name: $CI_COMMIT_BRANCH
You can see the predefined GitLab variables like the above used here
If you want to have further control to modify this variable during manual pipeline as you have asked in the question, GitLab provides that functionality, you can check it out here
I do not this that you can re-use variable defined or specified for one stage in another one. One of the key things of ci job is to be as much repeatable as possible, so jobs from the upcoming stages can't inherit variables from the previous one.
In my experience there are always some small differences between environments, so for me it make sense to almost copy/paste jobs definitions for different envs.
Is there a parameter or a setting for running pipelines in sequence in azure devops?
I currently have a single dev pipeline in my azure DevOps project. I use this for infrastructure because I build, test, and deploy using scripts in multiple stages in my pipeline.
My issue is that my stages are sequential, but my pipelines are not. If I run my pipeline multiple times back-to-back, agents will be assigned to every run and my deploy scripts will therefore run in parallel.
This is an issue if our developers commit close together because each commit kicks off a pipeline run.
You can reduce the number of parallel jobs to 1 in your project settings.
I swear there was a setting on the pipeline as well but I can't find it. You could do an API call as part or your build/release to pause and start the pipeline as well. Pause as the first step and start as the last step. This will ensure the active pipeline is the only one running.
There is a new update to Azure DevOps that will allow sequential pipeline runs. All you need to do is add a lockBehavior parameter to your YAML.
https://learn.microsoft.com/en-us/azure/devops/release-notes/2021/sprint-190-update
Bevan's solution can achieve what you want, but there has an disadvantage that you need to change the parallel number manually back and forth if sometimes need parallel job and other times need running in sequence. This is little unconvenient.
Until now, there's no directly configuration to forbid the pipeline running. But there has a workaruond that use an parameter to limit the agent used. You can set the demand in pipeline.
After set it, you'll don't need to change the parallel number back and forth any more. Just define the demand to limit the agent used. When the pipeline running, it will pick up the relevant agent to execute the pipeline.
But, as well, this still has disadvantage. This will also limit the job parallel.
I think this feature should be expand into Azure Devops thus user can have better experience of Azure Devops. You can raise the suggestion in our official Suggestion forum. Then vote it. Our product group and PMs will review it and consider taking it into next quarter roadmap.