I am using a pipeline build where my BuildConfiguration parameter has three values (debug, stage and release). The three consecutive builds all say Successful when run. The agent release directory folder only has the last one built! ..\a\release\build.2022.09.19.125822. Why does a multi-build only get one resulting build folder? I did copy these completed builds to another folder, but that seems like an extra step. Am I missing something? I have the "Clean" checkbox unmarked. TIA.
Related
I need to exclude a job from pipeline in case my project version is pre-release.
How I know it's a pre-release?
I set the following in the version info file, that all project files and tools use:
version = "1.2.3-pre"
From CI script, I parse the file, extract the version value, and know whether it's a pre-release or not, and can set the result in an environment variable.
The only way I know to exclude a job from pipeline is to use rules, while, I know also from gitlab docs that:
rules are evaluated before any jobs run
before_script also is claimed to be called with the script, i.e. after applying the rules.
I can stop the job, only after it starts from the script itself, based on the version value, but what I need is to extract the job from the pipeline in the first place, so it's not displayed in the pipeline history. Any idea?
Thanks
How do you run (start) your pipeline, and is the information whether "it's a pre-release" already known at this point?
If yes, then you could add a flag like IS_PRERELEASE as a variable to the pipeline, and use that in the rules: section of your job. The drawback is that this will not work with automatic pipelines (triggered by a commit or MR); but you can use this approach with manually triggered pipelines (https://docs.gitlab.com/ee/ci/variables/#override-a-variable-when-running-a-pipeline-manually) or via the API (https://docs.gitlab.com/ee/ci/triggers/#pass-cicd-variables-in-the-api-call).
I want to perform tests using gitlab CI using pytest-testmon. Unfortunately it seems that the generated file .testmondata is not saved in the gitlab-runner instances, so that no recollection of what was tested is saved.
Is there a way of saving this .testmondata and using it (for every different branch at test) in order to avoid repeating tests of unchanged code when code is pushed to those branches?
You can upload files generated during your job to Gitlab so you can view them later by downloading them, viewing on a Merge Request, or using them in other jobs by using the artifacts keyword. Here's a simple example:
tests:
stage: tests
script:
- ./run_tests.sh
artifacts:
paths:
- .testmondata
name: "$CI_COMMIT_REF_NAME_tests_testmondata"
expose_as: 'Tests Results'
expire_in: 3 months
In this example, after your script section (and before_script or after_script if present) runs, gitlab-runner will look for a file/directory that matches the entries in the paths array. If none are found, it will throw an error.
The runner will then upload the artifacts to Gitlab using the name in the name field. It's good practice to use some of the predefined variables that Gitlab CI provides so you can easily identify which pipeline and job an artifact came from, if necessary. In this example the name has the branch or tag name, and then _tests_testmondata.
The next attribute, expose_as lets you put a link on a Merge Request for this branch to display the artifacts. Without expose_as, you'll have to open the Pipeline and Job to view the artifacts.
Next, expire_in lets you define when the artifacts from this job should expire. If you don't set this attribute, the artifacts will expire based on the Gitlab server's setting, which by default is 30 days. You can supply a number of seconds as an int (3600, or one hour), never (to never expire), or many other human-readable formats like 3 years 8 months 28 days or 46 months.
You can view all the available predefined variables here: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html, and you can view all the options for the artifacts keyword here: https://docs.gitlab.com/ee/ci/yaml/#artifacts
I have some gitlab jobs in my pipleline which are slow and I'd like to prevent them from running when the changes will not affect the job's outcome.
This is what I have tried:
run_tests:
stage: checks
script:
- cargo test
except:
- master
- tags
only:
changes:
- "**/*.rs"
- "**/Cargo.toml"
- "**/Cargo.lock"
This sort of works. If a merge request has multiple commits, this job will not run on any of the commits after the first one, unless a Rust source file has changed.
But the job will still always run on the first commit of the branch, even if there are no changes to Rust source files between this branch and master. Even worse, if the tests fail on the first commit, subsequent commits might skip the tests so broken code could get merged.
How can I change this filter so that the diff is done against the target branch of the merge request?
Hidden quite deep in the documentation for only: changes, there is this snippet:
Without pipelines for merge requests, pipelines run on branches or tags that don’t have an explicit association with a merge request. In
this case, a previous SHA is used to calculate the diff, which
equivalent to git diff HEAD~. This could result in some unexpected
behavior, including:
When pushing a new branch or a new tag to GitLab, the policy always evaluates to true.
When pushing a new commit, the changed files are calculated using the previous commit as the base SHA
Which is the scenario you are currently experiencing, where the job always runs on the first commit of the new branch.
For this to work as you want, I believe you need to add only: merge_requests, however this would require changing your entire pipeline workflow to integrate only: merge_requests to your pipeline.
From the documentation:
With pipelines for merge requests, it’s possible to define a job to be
created based on files modified in a merge request.
In order to deduce the correct base SHA of the source branch, we
recommend combining this keyword with only: [merge_requests]. This
way, file differences are correctly calculated from any further
commits, thus all changes in the merge requests are properly tested in
pipelines.
Various issues from GitLab:
https://gitlab.com/gitlab-org/gitlab/-/issues/11427
https://gitlab.com/gitlab-org/gitlab/-/issues/27875
As part of our CI, after each release we create a new branch and manually change the version number in our AssemblyInfo and Config files. This is prone to human error and we have decided to automate this process. So far I have a script that creates a new branch from our Main branch which I run before our build; the XAML has been modified with a number of activities that checks out all the AssemblyInfo and config files, updates the version numbers and checks the changes in.
What I want to do is to make this two stage process into a single process. The idea I have at the moment is to add the "TF Branch" script as an invoke process at the beginning of my template before the "initialize Workspace" sequence; this will create the new branch (say branches\1.2.3.4). After the branch has been created I then use a "TFWorkFold" activity placed just under "Create Workspace", in the TFWorkFold activity I add the new mapping - ( ServerPath = $\TeamProject\Branches\1.2.3.4 - LocalPath = SourcesDirectory) but when the process hits the "Get Workspace" activity none of the source files from the new branch are added to the Workspace.
When I run this on other builds the new mapping is successful, only if the branch has been created before the build is initialized.
Is there a step i'm missing? In my Create branch script i have a ping timer of 600secs to allow the branching enough time to complete before the new workspace mapping is added
Figured it out,
After the new branch is created the build process needs to get the latest source files created. In the Build definition I need to tell it to get the Latest Version, this is set in the "Process" section under "Advanced" then "Get Version" I set the value as "T" for "Get Latest". Done :)
Basically I have a project A inside my cruisecontrol that has 2 different triggers. One is an intervalTrigger which checks to see if modification exists in the repository and the builds the project A. And the other one is a projectTrigger which makes the project A gets build if project B is built. Now I have a executable file and I only want this to deppen on my intervalTrigger and not on the projectTrigger. Is that possible???? How????
I'm not sure I understand what you're asking, but you can always create a new project C and set just the interval trigger to execute your file.