I have read GitLab's Use CI/CD Variables to Define Artifact Name documentation and examples.
In the following excerpt of my .gitlab-ci.yml file, I try to replicate their powershell example:
artifacts:
name: "$env:CI_JOB_STAGE-$env:CI_COMMIT_REF_NAME"
expire_in: 1 week
paths:
- My\Hardcoded\Path\*
But when I download the artifact, it's named: _env_CI_JOB_STAGE-_env_CI_COMMIT_REF_NAME.zip. I wanted to use a variable for my artifact path, but that didn't work either, so I was forced to hardcode it. What am I doing wrong?
I'm familiar with the open GitLab issue: Artifacts Filename Cannot Be Set with Dynamic Variables, and I would eventually like to put a date & timestamp in the artifact name, but first I'd just like to get any variable working.
I'm using GitLab v15.1.1-ee. My runner is v15.1.1, installed in Windows and uses a shell executor in powershell.
Per Ville Laurikari's comment, it appears this was a bug affecting v15.1.1. Today, I noticed that our GitLab instance was upgraded to v15.1.2-ee, and I replaced my runner with v15.1.0. The variables now work as documented.
Related
So I have a Jenkins job wherein as part of the build.
I run one script which creates a folder in the workspace say "test"
so the script runs fine and creates the folder test.
After this, I have a maven command wherein I want to access this test folder(as an argument) I am trying it as $workspace/test
but it's not working.
Can anyone guide if i am missing anything here
Can you give us more information - maybe code snippets?
I'm not sure what you mean with 'maven command' and '$workspace/test'
If you want use a variable in a pom.xml like:
<path>${workspace}</path>
you will have to assign it in the properties:
<workspace>...location...</workspace>
Otherwise you can use maven preassigned variables like
${basedir}/
I have a spring boot application and I deployed it in the first stage and now I have a jar file.
my question is how to access this jar file in the next stage and how I can run it.
second question is HOW can I increase its version number? for example jar file name is spring.0.0.1.jar and I want to increase version number after every push. is this possible?
First Question:
You can save the jar file as an artifact and access it in the second stages jobs' script area. For example
FirstJob:
stage: FirstStage
scrip:
- <your commands here>
artifacs:
paths:
- ./artifacts/myOutput.jar
Now your "myOutput.jar" is accessible in the artifacts folder for all following jobs. See here: https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html
Second Question:
As far as I know there is no way of handing down variables between pipelines in GitLab CI so this would not be possible if I'm right. Since artifacts don't get added to the repository, previous artifacts are not available to following pipelines either. Yet, if I had to come up with a solution on the spot, I'd try:
Saving the version number somewhere accessible to every pipeline (cloud, repo)
git push every artifact to actually add it to the repository, then check file name and increment version number
using the GitLab CI release option. The CI can create a release object for you, maybe this could help as well. See here: https://docs.gitlab.com/ee/ci/yaml/README.html#release
I'm investigating a Maven/Jenkins/Artifactory set up as a possible solution for a CI/Release process.
I have a job in Jenkins - call it MYJOB - that builds and deploys an artifact to Artifactory. Now, I want another job that I can run manually that will copy the artifact of a particular build of MYJOB from Artifactory and put it somewhere (not too bothered where right now, but eventually it'll be another server).
For example, let's say build #123 went green, and now my QA team want to deploy the built artifact to their environment for further testing (the idea being to keep this artifact intact and unchanged throughout the testing process, before marking it as releasable). I want them to be able to enter '123' into Jenkins as a job parameter and then kick off the build.
So, I figure I need a free-style job that uses a script to do this.
My question is: How can I pass the number of a previous MYJOB build to the job, so that it will get the correct artifact from artifactory?
Alternative methods of achieving my goal are welcomed :)
So I got it working. I put the following code in the Build Step section of a Jenkins Freestyle Build Configuration after defining a parameter called 'REQ_BUILD_NUMBER':
SOMETHING=$(curl "http://MYARTIFACTORYLOCATION/artifactory/api/search/prop?build.number=$REQ_BUILD_NUMBER" | jq --raw-output '.results[0].uri')
echo $SOMETHING
SOMETHING_ELSE=$(curl $SOMETHING | jq --raw-output '.downloadUri')
echo $SOMETHING_ELSE
wget -N --directory-prefix=/var/lib/jenkins/artifacts/ $SOMETHING_ELSE
(NB: I'm barely competent at shell scripting. I'm sure it can be done in a better way)
EDIT: This requires installing 'jq' for the command line.
Create a Parameterized build for the second job. The QA team can put the build number when they start the build. This build number will be available as an environment variable which can be accessed in the scripts which can then retrieve the packages from the repository.
I have a library that I want to use Travis-CI on.
It is written in Java and uses Gradle as a build system and deploy to Bintray.
When Travis-CI runs the tests, it fails because I do not store my username and password in plaintext in the git repo.
What went wrong:
A problem occurred evaluating root project 'project-name'.
Could not find property 'bintray_net_user' on com.jfrog.bintray.gradle.BintrayExtension_Decorated#18be0f81.
This is happening because I have not committed my gradle.properties.
How to I tell it not to run the deploy code, or otherwise fake it out?
I guess you're usually passing this property using -P commandLine option? The easiest fix for you might be to check if the property is available before you use it and initiate it with a sensible default if not:
if(!project.hasProperty('bintray_net_user')){
project.ext.bintray_net_user = 'default'
}
You can add user credentials stored to your .travis.yml secure environment variables.
Since you always have one of the two (local gradle.properties, or parsed .travis.yml), it will work correctly.
how can I copy the artifacts from Teamcity to another server?
Thanks
The way I have done this, make things a lot easier.. Setup another configuration that pulls in, via artifact dependencies, all the files you need then run a cmd script to xcopy/copy the files to another drive on the network. You can do this using cmd script, vbs, python, shell etc..
Remember, you only need to refer to directories as if they were local as you would have your script in the same working directory
i.e cmd script :: xcopy .\"my build artifact(s)" \path\to\drive\on\my\network\"my build artifacts"
It doesn't get easier than that.
Naturally, if your artifacts are huge, then you may want to consider your more complicated option. However, TeamCity currently have a ticket pending, which you can vote on, that allows you to run multiple runners in one configuration - so you could just add your cmd script to the same configuration to save the copy time; please vote if can spare a minute:
http://youtrack.jetbrains.net/issue/TW-3660
There is a Deployer plugin, that supports deploy by fileshare/SMB, FTP, SSH and other means. The usage is basically the same as the Artifact paths.
We have used just samba, so you must enter:
target Host path: //server/drive/myfolder
Username: mydomain\myusername - in our case we had to write domain
here too
Password: ****
Domain: mydomain
and in path just select the files as in artifacts:
product/* => product.zip
and it will create file //server/drive/myfolder/product.zip
You can do it from your build script or externally.
If you are looking to get artifacts copied from a remote build agent to the primary TeamCity server, you may want to look into configuring Build Artifacts under the General Settings.
According to TeamCity's wiki entry on BuildArtifacts (http://confluence.jetbrains.com/display/TCD7/Build+Artifact) "Upon build finish, TeamCity searches for artifacts in the build's checkout directory according to the specified artifact patterns. Matching files are then uploaded ("published") to the TeamCity server, where they become available for download through the web UI or can be used in other builds using artifact dependencies."