We have the following numbering for our development
(major version).(uat release number).(qa release number).(build number)
We have three Build configurations per branch
Build after commit (build number++)
Build and push to QA (qa ++)
Build and push to UAT (uat ++)
The major version is set only when branching and is manual.
What I need is the Version number in Teamcity itself to change according to these rules ACROSS ALL BUILD CONFIGURATIONS.
So if the build after commit becomes 2.0.0.14 and then it is pushed to QA it becomes 2.0.1.14 and then to UAT: 2.1.1.14
Related
We have a WordPress plugin written in JS with the help of the tool wp-reactivate.
Our goal is to make a GitLab CI Pipeline that increases the version in all places, builds the project and deploys it to the WordPress.org SVN repository. So far, the SVN deployment does work, incrementing the version number is unimplemented yet, but we have a problem building the project. The GitLab CI Runner refuses to finish the process since it ran out of available memory.
We have already tried (with no effect):
Setting GENERATE_SOURCEMAP=false
Setting NODE_OPTIONS="--max_old_space_size=8192"
Running node --max-old-space-size=8192
Our .gitlab-ci.yml file:
stages:
- build
- deploy
default:
image: node
BuildApp:
stage: build
before_script:
- GENERATE_SOURCEMAP=false
- NODE_OPTIONS=\"--max_old_space_size=8192\"
- node --max-old-space-size=8192
script:
- yarn
- yarn prod
PluginSVN:
stage: deploy
before_script:
- apt-get install subversion
- curl -o /usr/bin/deploy.sh https://git-cdn.e15r.co/open-source/wp-org-plugin-deploy/raw/master/scripts/deploy.sh
- chmod +x /usr/bin/deploy.sh
script: /usr/bin/deploy.sh
when: on_success
Is there any way to increase the amount of available memory, or reduce the amount of memory required for building the project?
Check Gitlab Forum:
Every runner only have 1CPU, 4GB RAM,
which means you don't have to adjust node options, it won't work.
For me, self-hosted is an option.
what ever I install gitlab-runner on self host, or docker, I got same issue.
Finally I got the root cause. The ec2 instance I created is too low, t2.micro
After I adjust it to t3.medium (you should be fine to adjust to any, with 4GB+ memory), it works without this issue any more.
I am using the desktop bridge for a WPF desktop application and am looking to automate the creation of my msix packages during build. I do not want to store any version information in source control.
The WPF project in the solution uses the gitversion msbuild task to automatically infer the version for my executable every time a build is done.
Unfortunately, I'm not sure if any such similar mechanism exists for .appxmanifest.
My thinking is that it would be nice to have this nicely integrated with the build process, similar to gitversion, but I haven't been able to find any documentation about what my options are during build or the Create App Packages process.
Perhaps there's some transform step during build that I'm not aware of that can be done to the .appxmanifest? Or maybe there's a way to have the version always reflect the version of the executable being bundled?
(MSDN forums question)
Your should modify the .appxmanifest file in your build pipeline before you create the package. After all, it's just a text-based XML file.
If you are using Azure Pipelines, you could accomsplish this using a Powershell task and a counter variable that gets incremented for each build:
pool:
vmImage: vs2017-win2016
variables:
buildPlatform: 'x86'
buildConfiguration: 'release'
major: 1
minor: 0
build: 0
revision: $[counter('rev', 0)]
steps:
- powershell: |
[Reflection.Assembly]::LoadWithPartialName("System.Xml.Linq")
$path = "Msix/Package.appxmanifest"
$doc = [System.Xml.Linq.XDocument]::Load($path)
$xName =
[System.Xml.Linq.XName]
"{http://schemas.microsoft.com/appx/manifest/foundation/windows10}Identity"
$doc.Root.Element($xName).Attribute("Version").Value =
"$(major).$(minor).$(build).$(revision)";
$doc.Save($path)
displayName: 'Version Package Manifest'
+Build, Package and Sign.
Please refer to this MSDN Magazine article for more information and a complete example of how to set up continuous integration (CI), continuous deployment (CD) and automatic updates of sideloaded MSIX packaged WPF applications using Azure Pipelines.
You must update the manifest before packaging. Check out this sample including a powershell script to poke the xml with the gitversion provided. https://github.com/microsoft/devops-for-windows-apps/blob/master/azure-pipelines.yml#L72
Everything used to work fine until today. Didn't change anything as far as I know and now I get this:
C:\mypath>gradle appengineDeploy
> Configure project :
WARNING: You are a using release candidate 2.0.0-rc1. Behavior of this plugin has changed since 1.3.5. Please see release notes at: https://github.com/GoogleCloudPlatform/app-gradle-plugin.
Missing a feature? Can't get it to work?, please file a bug at: https://github.com/GoogleCloudPlatform/app-gradle-plugin/issues.
> Task :appengineDeploy FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':appengineDeploy'.
> Deployment version must be defined or configured to read from system state
1. Set appengine.deploy.version = 'my-version'
2. Set appengine.deploy.version = 'GCLOUD_CONFIG' to have gcloud generate a version for you.
3. Using APPENGINE_CONFIG is not allowed for flexible environment projects
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
Deprecated Gradle features were used in this build, making it incompatible with Gradle 5.0.
See https://docs.gradle.org/4.8.1/userguide/command_line_interface.html#sec:command_line_warnings
BUILD FAILED in 6s
8 actionable tasks: 6 executed, 2 up-to-date
I just updated gradle from version 4.5.1 to 4.8.1 but the same issue remains. I understand it complains about version of the appengine but I never had to state that before so I think it's due to some update on Google's side. What am I missing?
You are now using the app-gradle-plugin version 2.0.0-rc1 as I can see from your console output, which was released 2 days ago. It has some changes, which the developers of the plugin documented.
As you can see in the Change Log of this release candidate from google, it mentions in the changes:
project and version are no longer pulled from the global gcloud state by default. project must be configured in build.gradle using the deploy.project property, users may use special keywords for project to specify that they would like to read it from appengine-web.xml (project = "APPENGINE_CONFIG") or from gcloud global state (project = "GCLOUD_CONFIG"). version is also configured the same way.
So you just have to specify in your gradle.build the following:
appengine {
deploy {
version = "GCLOUD_CONFIG"
project = "GCLOUD_CONFIG"
}
}
Update in 2.0.0-rc3 (Thanks to #wildcat12 for pointing it out)
in the latest version 2.0.0-rc3, the project configuration property has changed.
Changed appengine.deploy.project -> appengine.deploy.projectId
Therefore, now your gradle.build configuration would look like that:
appengine {
deploy {
version = "GCLOUD_CONFIG"
projectId = "GCLOUD_CONFIG"
}
}
If you are using
classpath 'com.google.cloud.tools:appengine-gradle-plugin:+'
line in your build.gradle file you are using the 2.0.0-rc3 release candidate version now. It is working well with last stable version: 1.3.5.
I have some misunderstandings about Karaf cluster Cellar replication.
We have 4 nodes, and all these nodes surrounding in the cluster.
First problem:
If we install feature in cluster (cluster:feature install) and execute command cluster:bundle-list default, we see that all bundles in this feature have local type in column Located, but the feature has cluster/local type.
How can I achieve that bundles have cluster/local type?
Second problem:
When we install feature in cluster (cluster:feature install) all bundles exist in all nodes (auto sync) but then when we synchronize manually (cluster:sync -g default) for example on 3 nodes we see that bundles does not exist on it any more.
To return feature bundles to 3 nodes we have to uninstall and install feature in cluster again.
Please comment this strange behaviour.
Version:
apache-servicemix-7.0.1
karaf 4.0.9
cellar 4.0.4
camel 2.16.5
CXF 3.1.9
Being windows users, we created one svn repo with a hierarchy of folders. The bottom nodes contain the svn standard layout:
ProjectA/
ApplicationOne/
ModuleX/
trunk/
branches/
tags/
ApplicationTwo/
ModuleY/
trunk/
branches/
tags/
... and so on ad infinitum. The repo now contains around 100+ real svn projects with the trunk/branches/tags structure, but almost none of them at the top level.
How would I configure subgit to handle this?
SubGit can work in two different modes: local mirror mode and remote mirror mode. Below you can find a general overview of these modes and some recommendations for your particular case.
Local Mirror Mode
In this mode both Subversion and Git repositories reside on the same host, so SubGit has local access to both SVN and Git sides.
Below I've provided basic instructions. Please find detailed documentation and common pitfalls in SubGit 'Local Mode' Book.
Configuration
subgit configure <SVN_REPO>
SubGit version <VERSION> build #<BUILD_NUMBER>
Detecting paths eligible for translation... done.
Subversion to Git mapping has been configured:
/ProjectA/ApplicationOne/ModuleX : <SVN_REPO>/git/ProjectA/ApplicationOne/ModuleX.git
/ProjectA/ApplicationTwo/ModuleY : <SVN_REPO>/git/ProjectA/ApplicationTwo/ModuleY.git
...
CONFIGURATION SUCCESSFUL
...
This command tries to auto-detect repository layout and generate configuration file at <SVN_REPO>/conf/subgit.conf. It may take a while in case of big Subversion repository like yours.
Please make sure that auto-generated configuration file looks as follows, adjust it if necessary:
...
[git "ProjectA/ApplicationOne/ModuleX"]
translationRoot = /ProjectA/ApplicationOne/ModuleX
repository = git//ProjectA/ApplicationOne/ModuleX.git
pathEncoding = UTF-8
trunk = trunk:refs/heads/master
branches = branches/*:refs/heads/*
shelves = shelves/*:refs/shelves/*
tags = tags/*:refs/tags/*
...
Authors mapping
At this stage you have to create /conf/authors.txt file that maps existing SVN usernames to Git authors. Please refer to documentation for more details.
Installation
Finally you have to import your Subversion repository to Git and enable synchronization by running subgit install command:
subgit install repo
SubGit version <VERSION> build #<BUILD_NUMBER>
Subversion to Git mapping has been found:
/ProjectA/ApplicationOne/ModuleX : <SVN_REPO>/git/ProjectA/ApplicationOne/ModuleX.git
/ProjectA/ApplicationTwo/ModuleY : <SVN_REPO>/git/ProjectA/ApplicationTwo/ModuleY.git
...
Processing '/ProjectA/ApplicationOne/ModuleX'
Translating Subversion revisions to Git commits...
Processing '/ProjectA/ApplicationTwo/ModuleY'
Translating Subversion revisions to Git commits...
...
Subversion revisions translated: <REVISIONS_NUMBER>.
Total time: <TIME_SPENT> seconds.
INSTALLATION SUCCESSFUL
Git Server
When the installation is over and synchronization between Subversion and Git repositories is enabled, you can setup some Git server (or reuse existing Apache HTTP server). Please refer to documentation on that and see a couple of posts on this topic in our blog:
VisualSVN Server and SubGit
Gitolite and SubGit
Remote Mirror Mode
When using this mode one has to install SubGit into Git repository only and keep this repository synchronized with remote Subversion server hosted on a different machine.
Below you can find some basic instructions. Please refer to SubGit 'Remote Mode' Book for more details.
Configuration
In remote mirror mode SubGit does not try to auto-detect repository layout, so you have to run subgit configure --svn-url <SVN_URL> command for every module within Subversion repository:
subgit configure --svn-url <SVN_ROOT_URL>/ProjectA/ApplicationOne/ModuleX <GIT_ROOT_DIR>/ProjectA/ApplicationOne/ModuleX.git
SubGit version <VERSION> build #<BUILD_NUMBER>
Configuring writable Git mirror of remote Subversion repository:
Subversion repository URL : <SVN_ROOT_URL>/ProjectA/ApplicationOne/ModuleX
Git repository location : <GIT_ROOT_DIR>/ProjectA/ApplicationOne/ModuleX.git
CONFIGURATION SUCCESSFUL
...
As result SubGit generates configuration file <GIT_REPO>/subgit/config for every Git repository. For your case this configuration file should look as follows:
...
[svn]
url = <SVN_ROOT_URL>/ProjectA/ApplicationOne/ModuleX
trunk = trunk:refs/heads/master
branches = branches/*:refs/heads/*
tags = tags/*:refs/tags/*
shelves = shelves/*:refs/shelves/*
fetchInterval = 60
connectTimeout = 30
readTimeout = 60
keepGitCommitTime = false
auth = default
[auth "default"]
passwords = subgit/passwd
useDefaultSubversionConfigurationDirectory = false
subversionConfigurationDirectory = <SVN_CONFIG_DIR>
...
Authors mapping
At this stage you have to create /subgit/authors.txt file that maps existing SVN usernames to Git authors. Please refer to documentation for more details.
SVN credentials
In case you're not using file:// protocol you have to provide necessary credentials, so SubGit is able to authenticate against Subversion server. For more information on that please read corresponding chapter in SubGit Book.
We also recommend enabling pre-revprop-change hook on Subversion side which makes further installation and maintenance a bit easier, see SubGit Book.
Installation
Finally you have to import your Subversion repository to Git and enable synchronization by running subgit install command:
subgit install git
SubGit version <VERSION> build #<BUILD_NUMBER>
Translating Subversion revisions to Git commits...
Subversion revisions translated: <REVISIONS_NUMBER>.
Total time: <TIME_SPENT> seconds.
INSTALLATION SUCCESSFUL
This command also launches background process that polls SVN server and fetches new revisions when they appear there. Basically, that means that SubGit uses dedicated process for every Git repository. Sometimes it makes sense to avoid running such processes and use some job scheduler instead.
Git server
Those links I've provided above are relevant for remote mode as well.
However, if you're going to use Atlassian Stash for Git hosting, you can use SVN Mirror Plugin which is based on SubGit engine and provides some better experience with regards to UI and maintenance.
We have the following guideline which is based on our experience:
In case of many independent Subversion repositories, it's better to use SubGit in local mirror mode as it doesn't require SVN polling and maintaining additional process(es) for that.
In case of one giant Subversion repository with many modules, it's better to use remote mirror mode with file:// protocol and also adjust basic setup slightly.
It definitely doesn't make sense to run 100+ background processes in your case, instead we recommend installing additional post-commit SVN hook that checks what particular modules were modified by a given revision and then triggers synchronization for corresponding Git repositories.
If you have any other questions, feel free to ask us here at Stack Overflow, at our issue tracker or contact us via email: support#subgit.com.