I want to build a project in Azure Pipelines, but I want to know what the idiomatic way is to obtain the latest tag, latest tag distance, and repo remote path/URL in order to pass those values into the actual build script that is inside the repository.
Previously our build script would invoke hg log -r . --template with a clever template, but we found when moving to Continua CI build server that the build agent doesn't have access to the actual repository during a build, and had to find another way.
I'm assuming the same issue would crop up with Azure Pipelines and haven't quite found the relevant docs yet on artifact versioning.
Many thanks in advance.
For git at least, Azure Pipelines does a full clone of the repo by default, unless you explicitly denote that you're doing a shallow clone (source: https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/pipeline-options-for-git?view=azure-devops).
Deriving the version/tag can be done via normal git commands (i.e. git describe --tags or whatever you prefer), which can then be saved as VSO variables to be accessed in later steps in the same job (see https://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch#set-variables-using-expressions for more info on how to do that).
Related
I want to set an opensource project where users can be sure that the deployed version .heroku.com corresponds with the actual source code in github master branch github.com/
Is there any way to prove a heroku deployment corresponds to a github repo?
Your app can spit out the latest deployed Git SHA if it has the "Dyno Metadata" feature turned on: https://devcenter.heroku.com/articles/dyno-metadata
Using that, you can show the latest SHA and compare it against the public repo.
Also, to add to what Jon said, you can do this via the heroku releases command. Every release, be it a code deployment, config var is 'tagged' - the command will show you everything that has changed on your app and a deploy will show the short git SHA, you can copy the SHA and then use the git command to search the repo for it.
eg.
assuming heroku releases returns
v10 Deploy 33f21247 foo#bah.com 2018/09/03 10:01:38 +0100
then you could do:
git cat-file commit 33f21247
which will then output the corresponding match, or a message saying it's not found. Obviously, this assumes your local repo is in sync with GitHub. To check it against GitHub you'd need to open your repo on GitHub like:
https://github.com/heroku/{projectname}/commit/{sha}
which will show the same commit on GitHub.
Since travis-ci.org doesn't support bitbucket.org I need another CI service which supports it and allows managing the build commands in a VCS file (like .travis.yml in travis).
My quite annoying research result so far is:
semaphoreci.com: projects which are forks aren't listed even after refreshing the project list
app.shippable.com: signing up with both github.com and bitbucket.org doesn't work
codeship.com: doesn't support to run commands as ''root'' user((https://codeship.com/documentation/faq/root-level-access/))
www.snap-ci.com: no support for bitbucket.org((http://www.slant.co/topics/186/~hosted-continuous-integration-services))
I don't get why people would not want to share the CI service build commands in the VCS - chances of good collaboration without such a feature seems small to me. Even if one adds a script file in the VCS it still needs to be set up in the CI service which appears to be an unnecessary step.
A few months ago Bitbucket launched Pipelines. Quoting from the link:
Continuous delivery is now seamlessly integrated into your Bitbucket Cloud repositories.
You may use it on free plans, but next year they will reduce the build minutes for free plans from 500 minutes to 50 minutes as told in this link.
Also, CircleCI is supporting Bitbucket. It has free plan with 1500 build minutes. It can be triggered by commit or tag in BB. https://circleci.com/
The company that owns BitBucket also has a product called Bamboo for CI. Though most should work with any git that provides a webhook.
According to this blog, it is possible to use Travis-CI for Bitbucket:
Clone github repository:
git clone https://github.com/{github_user}/{github_repository}
cd {github_repository}
Add submodule bitbucket repository:
git submodule add https://bitbucket.org/{bitbucket_user}/{bitbucket_repository}
Add .travis.yml to root dir:
git:
submodules:
false
before_install:
- echo -e "machine bitbucket.org\n login $BITBUCKET_USER_NAME\n password $BITBUCKET_USER_PASSWORD" >~/.netrc
- git submodule update --init --recursive
$BITBUCKET_USER_NAME is bitbucket username
$BITBUCKET_USER_PASSWORD is app password
Open https://travis-ci.org/{github_user}/{github_repository}
A Semaphore CI user can add a fork of a project to his Semaphore account following these steps on the documentation page. Also, Semaphore is building a fork pull request and those builds are visible.
There also is (now) an option to use GitLab as CI/CD server for repository hosted on Bitbucket.
See the documentation here: on GitLab site
Since GitLab 7.6, or thereabouts, there is a new option to use TeamCity directly from GitLab projects. In the setup there is this message:
The build configuration in Teamcity must use the build format number
%build.vcs.number% you will also want to configure monitoring of all
branches so merge requests build, that setting is in the vsc root
advanced settings.
I'm not sure how this works. Lets say I have a repository Foo.
I have setup a build on TeamCity to listen to Foo with branch specification: +:refs/pull/*/merge
I then fork Foo in gitlab as FooFork, make a change, then request a merge FooFork -> Foo.
But nothing happens to test this merge, which is what I was expecting GitLab to do. If I accept the merge than the build server jumps into action (immediately) and builds twice (master and /ref/master).
I've also set the build configuration to use exactly: %build.vcs.number% as the build number as prescribed, but gitlab doesn't seem to give me any information about the build result.
So I'm a bit confused really as to what exactly this GitLab -> TeamCity integration is supposed to do and whether I'm doing wrong.
I'm currently running GitLab 7.9 and TeamCity 8.1.4
Update:
Seems this use case was not supported prior to version 8 - https://github.com/gitlabhq/gitlabhq/issues/7240
I'm running GitLab 8.0.2 and TeamCity 9.1.1 and am able to run CI builds on branches and merge requests.
I trigger CI builds for specific branches by setting a VCS trigger together with the branch specification +:refs/heads/(xyz*) where xyz is the string for our ticket system prefix since all active branches need to be named after an entry in our issue tracker.
I trigger builds for merge requests via the branch specification +:refs/(merge-requests/*)
Everything works as as expected and lets us know the status of all feature / bug branches and merge requests automatically.
Thanks to Rob's comment linking to the GitLab 8 release notes entry on the merge request spec.
Same problem here. There might be another way, I'm evaluating right now. Since there's no direct way of getting the merged state from the target MR, you have to build it on your own:
IMO there's the following todos
1.) init a bare repo $ git init
2.) add your target repo $ git remote add origin git#your-repo:<origin.group>/<origin.repo>.git
3.) add the remote/feature/to-merge's $ git remote add target git#your-repo:<feature.group>/<feature.repo>.git
4.) checkout your feature branch $ git checkout -b <feature.branch> feature/<feature.branch>
5.) checkout your original branch $ git checkout -b <origin.branch> origin/<origin.branch>
6.) Rebase feature into your original branch $ git rebase <feature.branch>
As stated here [1], GitLab-CE can fire an event on creation of a merge-request,
so all you have to do is building some meta, that can evaluate the WebHooks.
[1] http://doc.gitlab.com/ce/web_hooks/web_hooks.html#merge-request-events
Helo,
I'm using Bamboo to deploy a Java webapp project that's triggered by git repo push. My requirement is to deploy based on conditions,
"branch is pushed" and
"new commit is tagged as some value"
Is it possible to be done using existing plugin? If I have to implement it manually, is it possible? how to?
There may be simple and more direct ways of doing this with the latest Atlassian Bamboo major release (version 5, see https://www.atlassian.com/software/bamboo/deploy). I would certainly embrace some additional automation/deployment workflows around these types of features, but I implemented something akin to what you're asking for without plugins and have been using it quite successfully for eight months.
Here's how it works:
We merge to a testing branch which executes a suite of unit, integration, functional, and workflow tests, and builds various pieces of documentation. This is like your (1): "branch is pushed"
We run a second manual plan which pulls the latest testing branch, tags it, and pushes the tag.
Our third step is to run a deployment plan which deploys the latest tag.
I think step (1) and (3) will vary widely between applications. Step (2) however may hit on what you're after. Here's the details regarding that plan and its associated task:
Checkout the testing branch, Force Clean Build is enabled
Use an inline script to add a remote repository. E.g., a GitHub example:
git remote add origin git#github.com:/repo.git || exit 0
Use the git excutable with arguments pull origin testing to ensure we're consistent with the upstream repository
Use the git excutable with arguments fetch --all --tags to get the latest tags from all repositories
Use a bash executable with a custom script to change the version of our codebase to what the tag will be named.
Use the git excutable with arguments push origin --tags to push the tag created in the previous step.
The custom script mentioned in (5) looks like this:
scripts/version.sh ${DATE}
git commit -m "bumped version"
git tag -af "${DATE}" -m "Build server tagged ${DATE}"
For completeness, I'm using || exit 1 everywhere within scripts to make sure they fail-fast but left these out for brevity.
tl;dr No plugins support what you're asking for to my knowledge. It is possible. The how will vary for you, hopefully what I've set forth shows that.
I would to run buildr on my svn repository - to build the files from \src\main\java in the subversion repository with username and password and save it to anther location on my disc.
How can I do it?
if i understand your question correctly, you are trying to setup a contiuous build system. checking out source code is the responsibility of your CI system. it would poll your svn, git or whatever cvs you use for changes and then build it on the configuration you provide.
a free build-server is jenkins (aka hudson). if you want a hosted solution you can go for travis-ci (it's free). or something expensive like atlassian bamboo.
You will have to write an Ruby build script - that when you execute will:
Checkout the source
do the 'buildr'
Commit the built file(s)
http://www.markdeepwell.com/2010/06/ruby-subversion-bindings/
http://blog.carlossanchez.eu/2009/08/18/using-subversion-ruby-bindings/
the easiest way is run external svn commands
task :checkout do
system 'svn checkout ..'
end