If you run GitVersion /showConfig with no config file present, you'll see that there are a bunch of default branch configs. If you set up a branch config in the config file:
branches:
example:
regex: "example"
source-branches: []
then show config will show this at the beginning of the branch list. If you set up a branch with the same name as an existing default branch config:
master:
increment: Minor
then show config will merge this setting with the default master branch and move it to the top:
branches:
master:
mode: ContinuousDeployment
tag: ''
increment: Minor
prevent-increment-of-merged-branch-version: true
track-merge-target: false
regex: ^master$
source-branches:
- develop
- release
tracks-release-branches: false
is-release-branch: false
is-mainline: true
pre-release-weight: 55000
This could be handy sometimes, but other times it just annoyingly means that your branch has an unexpected config or that your regex fails to match and one of the other default branch configs matches.
How can I get GitVersion to completely replace its default branch configs with the config I give and not merge either the list or the settings of each branch?
GitVersion uses all the settings shown when it calculates the Semantic version for your project on a given branch.
When you provide your own configuration, what you're really doing is overriding the default configuration. If you don't provide an overridden configuration value for an item in a branch configuration, the default configuration value for that branch is used. So even though you don't provide it, it's inherited. The alternative is for you to specify each and every setting for your branch configurations to completely override and customize how GitVersion works for you.
Again, this is necessary, because these configurations are used whenever GitVersion calculates a version for your project.
Related
$CI_ENVIRONMENT_NAME doesn't work with rules:changes. Is it expected behaviour?
rules:
- changes: # Include the job and set to when:manual if any of the follow paths match a modified file.
- authurl/config/$CI_ENVIRONMENT_NAME/*
when: manual
allow_failure: false
As soon as the variable replaced with a static value the rule stars working.
The docs mention that $CI_ENVIRONMENT_NAME is available only if environment:name is set.
For expected behavior, you might have to add the environment value to the job.
I have written a Git pipeline gitlab.yaml, where I am having both except and only rules.
I have a design/ folder which I am ignoring for most of the jobs and, except this folder, all my pipeline should get executed.
only:
refs:
- master
except:
changes:
- design/*
But: when I make changes to design folder file, and other files, then all the jobs are not getting executed.
Note: depending on your GitLab version (or with gitlab.com), you need to rewrite your exclusion rules using rules:
See "Transitioning your only/except syntax to rules".
The question "Gitlab CI how to ignore directory using rules syntax?".
However, as illustrated with gitlab-org/gitlab issue 301070, this new syntax does not solve your issue.
Currently it seems not to be possible to use rules:changes: to trigger a job when certain globs match, ignoring other sets of globs.
So for now, this is still being discussed/fixed.
You can try this glob pattern:
job:
rules:
- if: $CI_COMMIT_BRANCH == "master"
changes:
- '[!design]*/**'
I have Serverless application that has two stages: develop (on branch develop) and master (on branch master).
It has a file called config.js like this:
API_URL: api.prod.some-server.com
But I want that "prod" changed to "dev" when I'm on develop branch / on develop stage environment.
It's kinda exhausting if I should change the API_URL back-and-forth (prod -> dev) when I changed the current branch/dev_stage.
Is there any possible to automate this?
Thank you
Is there any possible to automate this?
Yes: You would need to not version config.js (keep it private), but to generate it (with the right value in it).
The generation script will determine the name of the checked out branch with:
branch=$(git rev-parse --symbolic --abbrev-ref HEAD)
Or (since Git 2.22, Q2 2019)
branch=$(git branch --show-current)
That means you could:
version only a template file config.js.tpl
version value files named after the branches: config.js.dev, config.js.master: since they are different, there is no merge issue when merging or switching branches.
Finally, you would register (in a .gitattributes declaration) a content filter driver.
(image from "Customizing Git - Git Attributes", from "Pro Git book")
The smudge script, associated to the template file (config.js.tpl), would generate (automatically, on git checkout) the actual config.js file by looking values in the right config.js.<branch> value file.
The generated actual config.js file remains ignored (by the .gitignore).
See a complete example at "git smudge/clean filter between branches".
I prefer to organize my artifacts in Artifactory in a hierarchy of Repo[dev|test|prod] -> Artifact Name -> Releases Artifacts go here -> Pre-Releases go into a sub-folder.
Why? So when I am navigating the Artifactory Repository Browser I don't have an exceedingly long tree. I can expand a repository and see the first level by artifact name and still not see any artifacts, then expand the artifact name leaf and then see my released artifacts. But, the top item underneath will be a sub-directory folder called "prerelease". This is done so I can easily manually delete all my pre-releases if I wish to do so in one action, or schedule to clean them up.
[My Repo]
|
+-\prerelease\
| |--artifact-1.2.3-ci0004.nupkg
| |--artifact-1.0.1-ci0002.nupkg
|--artifact-1.0.0.nupkg
|--artifact-1.0.1.nupkg
I know how to use the Artifactory filespec to upload the package to my repository:
** For Pre-Release
{
"files": [
{
"pattern": "$(build.artifactstagingdirectory)\*.nupkg",
"target": "myrepo-nuget-dev-local/$(PackageName)/prerelease/"
}
]
}
** For Release
{
"files": [
{
"pattern": "$(build.artifactstagingdirectory)\*.nupkg",
"target": "myrepo-nuget-dev-local/$(PackageName)/"
}
]
}
What I need to do is put each file spec into its own build step and then add conditions that will execute EITHER one build step OR the other, but never both. Why? Because the build artifact will ever be a pre-release or a release artifact but never both. I am using GitVersion and Git Tags along with Azure DevOps.
So the question: What does the Custom Condition need to be to get this working?
This logic should work for any CI system, but this syntax will work for Azure DevOps.
How to create these can be found here: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/expressions?view=azure-devops
Here is what it looks like:
For Pre-Release:
and(succeeded(), not(startsWith(variables['GitVersion.BranchName'], 'tags/')), or(ne(variables['GitVersion.PreReleaseLabel'], ''),ne(variables['GitVersion.BuildMetaData'], '')))
This is saying all 3 conditions MUST be met:
if succeeding
GitVersion.BranchName does not start with 'tags/' (this makes sure this build event was not triggered by a tag), and,
GitVersion.PreReleaseLabel is not empty OR GitVersion.BuildMetaData is not empty
For Release:
and(succeeded(), or(and(eq(variables['GitVersion.PreReleaseLabel'], ''), eq(variables['GitVersion.BuildMetaData'], ''), eq(variables['GitVersion.BranchName'], 'master')), startsWith(variables['GitVersion.BranchName'], 'tags/')), ne(variables['Build.Reason'], 'PullRequest'))
This is saying all 3 conditions MUST be met:
if succeeding
(GitVersion.PreReleaseLabel is empty AND GitVersion.BuildMetaData is empty AND GitVersion.BranchName is 'master') OR (GitVersion.BranchName starts with 'tags/')
Build.Reason is not 'PullRequest'
Here is what it looks like:
I have an agent/master setup. I have created a new environment in /etc/puppetlabs/code/environments/ called master.
The content of environment.conf for the master directory environment is
modulepath = site:modules:$basemodulepath
manifest = manifests/site.pp
and when I try puppet agent -t --environment master I am getting some error
Notice: Local environment: 'master' doesn't match server specified node environment 'production', switching agent to 'production'.
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Info: Caching catalog for node1.localpuppet.com
Info: Applying configuration version '1490712072'
Notice: Applied catalog in 0.67 seconds
I am new to puppet. What changes do I need?
PE Console Config
This is a "really fun" quirk of Puppet Enterprise that showed up in the last couple of years. You have to specify the nodes in the PE Classifier that are allowed to specify their directory environment in the puppet.conf or in the puppet agent -t --environment arguments.
In the agent-specified environment tab in the Classifier (you see it at the bottom of your picture above), you can enable it for all nodes. Do this by adding a rule, selecting the name fact, using a regular expression (~), then using the regexp for matching all characters (.*). After you fill this out, the PE Classifier will give you a number of matching nodes. It should be all that are subscribed to your master. Remember to click in the bottom right to update your rules. Your nodes will now be able to use master instead of production from the config file or CLI arguments.
That being said, if you are doing this to avoid naming your default Git branch production in your control repository when working with Code Manager, you should really just rename the branch as that is much easier.