We have a copy of to-be-continuous at Orange, which is currently used like this:
include:
# Python template
- project: "to-be-continuous/python"
ref: "1.2.2"
file: "/templates/gitlab-ci-python.yml"
However I have no idea how the sync works with the Orange repo, and I'm thinking it's better to make all projects directly include the gitlab.com link for faster access to new functionnalities, what do you think, do you expect any issues, security or operational wise?
include:
# Python template
- remote: 'https://gitlab.com/to-be-continuous/python/-/raw/1.2.2/templates/gitlab-ci-python.yml'
To-be-continuous at Orange are syncronised every night with gitlab.com. So you don't miss any newer functionalities. My suggestion is to use 1st include, because our internal repo have more customisation for our needs like devops-store variant, ODE..
Prefer use first include for all current cases.
You have to use second include for example to validate a new functionality not yet merged.
The include/remote may work but requires that your GitLab server has a direct access to the referenced link (gitlab.com in your case).
/!\ the include/remote syntax doesn't not support double include: when you're trying to include a template that itself includes a (local) template.
Related
I have a repo in which I manage Terraformcode for multiple environments.
For example I would have these files:
/terraform/dev/superapp/main.tf
/terraform/prod/superapp/main.tf
In those files, I define the used providers, modules, etc. The versions of those components are identical on dev and prod.
I enabled renovate on that repo and it works almost perfectly.
But renovate will open a PR that updates the versions for e.g. the aws provider or the eks-module in dev and prod in just one PR.
But I would like to have separate PRs for each module, provider, etc and then again separate PRs for dev and prod.
So I would end up with four PRs regarding the aws-provider and the eks-module.
One for each dependency in each environment.
I checked the docs of Renovate, but I could not really find out which parameter would trigger such a behaviour, but I am sure this has to be possible.
Any help is much appreciated.
You can specify the configuration option additionalBranchPrefix to add a prefix to the branch name created by Renovate. By using parentDir or baseDir in the prefix, Renovate will split PRs based on where the package definition is located.
In your case, since the immediate parent directory has the same name (superapp), you would have to use baseDir to take into account the whole path of the file to update.
Adding this configuration in renovate.json should do the trick:
{
"packageRules": [
{
"managers": ["terraform"],
"additionalBranchPrefix": "{{baseDir}}-",
"packagePatterns": [".*"]
}
]
}
As far as I know that is not possible at the moment with renovate.
You could try and include the files/paths one by one, but I do not think that will work.
Is there some integration available in GitLab for various linters/formatting tools?
Of course, you can always manually program a pipeline step that'd get the tested diffs, run the tool on them and fail if it encounters any issues, but that's suboptimal from usability perspective (especially for huge diffs/logs).
I.e. some review tools support posting the lint/codestyle check results inline (see https://github.com/traveloka/hubormaster as an example of what I'd ideally want to achieve).
Is anything like this possible in the current GitLab? Is there a tracking issue for this?
I believe you can use Danger for something like this. You'd need a job which does the linting / formatting, and then have a Dangerfile (with some Ruby, if you use that option), which formats the message to include the line number.
You can check the reference for their GitLab integration and options available.
Short example:
.gitlab-ci.yml:
danger:
stage: lint
image: <docker image with Danger>
script:
- danger --version
- danger --dangerfile=Dangerfile --verbose
tags:
- docker
Dangerfile:
warn("Please add something", file: "README.md", line: 1)
I am trying to set a module's source (this IS NOT a resource) based on a conditional trigger but it looks like the module is getting fired before the logic is applied:
module "my_module" {
source = "${var.my_field == "" ? var.standard_repo : var.custom_repo}"
stuff...
more stuff...
}
I have created the standard_repo and custom_repo vars as well and defined with URLs for respective repos (using git:: -- this all works w/o conditional)
All this being said, anyone know of a way to implement this conditional aspect? (again, this is a module and not a resource)
I tried using duplicate modules and calling based off the var value but this, too, does not work (condition is never met, even when it is):
repo = ["${var.my_field == "na" ? module.my_module_old : module.my_module_new}"]
One way to achieve this is described in this post
Basically, a common pattern is to have several folders for different environments such as dev/tst/prd. These environments often reuse large parts of the codebase. Some may be abstracted as modules, but there is still often a large common file which is either copy-pasted or symlinked.
The post offers a way that doesn't conditionally disable based on variables but it probably solves your issue of enabling a module based on different enviornments. It makes use of the override feature of terraform and adds a infra_override.tf file. Here, it defines a different source for the module which points to an empty directory. Voila, a disabled module.
Variables are not allowed to be used in the module source parameter. There also does not seem to be a plan for this to change. https://github.com/hashicorp/terraform/issues/1439 . Creating a wrapper script , or using something like mustache http://mustache.github.io/ seems to be the best way to solve the problem.
I have a cucumber feature file 'A' that serves as setting up environment (data clean up and initialization). I want to have it executed before all other feature files can run.
It's it kind of like #before hook as in http://zsoltfabok.com/blog/2012/09/cucumber-jvm-hooks/. However, that does not work because my feature files 'A' contains hundreds of cucumber steps and it is not as simple as:
#Before
public void beforeScenario() {
tomcat.start();
tomcat.deploy("munger");
browser = new FirefoxDriver();
}
instead it's better to be able to run 'A' as a feature file as a whole.
I've searched around but did not find a answer. I am so surprised that no one has this type of requirement before.
The closest i found is 'background'. But that means i can have only one huge feature file with the content of 'A' as 'background' at the top, and rest of my test in the same file. I really do not want to do that.
Any suggestions?
By default, Cucumber features are run single thread in order by:
Alphabetically by feature file directory
Alphabetically by feature file name within directory
Scenario execution is then by order within the feature file.
So have your initialization feature in the first directory (alhpabetically) with a file name that sorts first (alphabetically) in that directory.
That being said it is generally a bad practice to require an execution order in your feature files. We run our feature files in parallel so order is meaningless. For Jenkins or TeamCity you could add a build step that executes the one feature file followed by a second build step that executes the rest of your feature files.
I have also a project, where we have a single feature file, that contains a very long scenario called Scenario: Test data with a lot of very long scenarios, like this:
Given the system knows about the following employees
|uuid|user-key|name|nickname|
|1|0101140000|Anna|annie|
... hundreds of lines like this follow ...
We see this long SystemKnows scenarios as quite valuable, so that our testers, Product Owner and developers have a baseline of what data are in the system. Our domain is quite complex, and we need this baseline of reference data for everyone to be able to understand the tests.
(These reference data become almost like well known personas, and are a shared team metaphore)
In the beginning, we were relying on the alphabetic naming convention, to have the AAA.feature to be run first.
Later, we discovered that this setup was brittle, and decided to use the following trick, inspired by the PageObject pattern:
Add a background with the single line Given(~'^I set test data for all feature files$')
In the step definition, have a factory to create the test data, and make sure inside the factore method, that it is only created once, like testFactory.createTestData()
In this way, you have both the convenience of expressing reference setup as a scenario, that enhances team communication, but you also have a stable test setup.
Hope this is helpful!
Agata
I'm currently working on a deployment script to run as part of my GitLab CI setup. What I want is to copy a file from one location to another and rename it.
Now I want to be able to find what commit that file was generated with, so I'd like to add the hash of the commit to it.
For that to work I'd like to use something like this:
cp myLogFile.log /var/log/gitlab-runs/$COMMITHASH.log
The output should be a file named eg.
/var/log/gitlab-runs/9b43adf.log
How is this possible to achieve using GitLab CI?
In your example you used the short git hash that you would get with the predefined variable CI_COMMIT_SHA by building a substring like this:
${CI_COMMIT_SHA:0:8}
or by using the short sha directly
$CI_COMMIT_SHORT_SHA
The variable you are looking for is CI_COMMIT_SHA (formerly CI_BUILD_REF in GitLab 8.x and earlier) which one of the predefined variables.
All predefined variables are listed here.
Since GitLab v11.7 you can use $CI_COMMIT_SHORT_SHA which returns the first eight characters of CI_COMMIT_SHA.