I am setting up the security for our team city build server. I would like all users to be able to view all builds, some of these builds produce artifacts with sensitive data in (connection strings and the like). Is it possible to prevent a particular role from viewing build artifacts?
Possibly a bit of a workaround, but what about if you had two builds in a build chain? The first produces the artifacts but doesn't publish them and would be visible to all users; the second doesn't have any build steps and just publishes your sensitive artifacts.
Would that work in your case?
Related
Wondering how people manage their project artefacts through an environment lifecycle of say DEV - AQA - CQA - RELEASE and if there's some best practices to follow.
I use a Jenkins build server to build my projects (code checkout then maven build). My artefacts all have version 1.0.0-SNAPSHOT and are published to a local .m2 repo on the build server. There are also Jenkins jobs that rebuild the DEV system (on the same server) using those artefacts. The project build is automated whenever someone checks in code. The DEV build is automated on a nightly basis.
At some point, my lead developer determines that our project is fit to go to AQA (the first level of testing environment on a different server).
For this I need to mark the artefacts as version 1.0.0-1 and publish to a remote AQA repository (it's actually a Nexus repo).
The Maven deploy plugin sounds like the right approach, but how do I change the version number to be effectively 1.0.0-$release (where $release is just an incrementing number starting from 1)? Would Maven/Nexus be able to manage the value of $release, or would I need a simple properties file in my project to store/update the last used $release.
Furthermore, someone tests AQA and determines its fit to move on to CQA (second testing env). This is 'promote to AQA'. So my requirement is to copy the artefact from the AQA Nexus repo and publish to the CQA Nexus repo.
Likewise, after CQA, there'd be a 'promote to RELEASE' job too.
I think the version value remains unchanged during the 'promote' phases. I'd expect the AQA repo to see all versions 1-50, but CQA only 25 and 50, then RELEASE only 50, for example.
I can find loads of info about Maven plugins/goals/phases, but very little about a prescriptive method on how or where to use outside of the immediate development environment.
Any suggestions gratefully received.
Staging/promoting is out of scope for Maven. Once deployed/uploaded to a remote repository, that system is responsible for the completion of the release cycle. Read this chapter about staging: http://books.sonatype.com/nexus-book/reference/staging.html if you use Nexus.
Build numbers are just that build numbers. They are not promotion / staging numbers.
You should come up with another means of tracking your promotions, because otherwise one might get confused in "knowing" that build 10.1.4-2 is the same as 10.1.4-6. Certainly, all of the Maven related software will see those two builds as different builds.
In addition, if a person "grabs" the wrong copy of the build, the way you are managing staging within your build number will increase confusion. As if you don't kill all of the 10.1.4-2 builds, then someone might get a copy of that not realizing that the build has been promoted to 10.1.4-6. This means that for the "last" staging number to be the most likely one to be grabbed, you must do two things (which are impossible in combination)
Remove all the old staging numbers, updating them to the new ones.
Ensure that no copy of an old staging number escaped the update.
Since people generally can copy files without being tracked, or said files might not be reachable at time up "update", or timing between reaching all the files cannot be simultaneous, such a system is doomed to fail.
Instead, I recommend (if you must track by file), placing the same file in different "staging directories". This defines release gateways by whether the file exists in a certain directory, and makes it clear that it is the same file that is going through the entire process. In addition, it becomes easy to have various stages of verification poll their respective directories (and you can write Jenkins tasks to promote from one directory to another, if you really wish).
We have several projects undergoing, and there are dependencies relationships among them. All projects makes up a final software.
We set up a DEV build environment to do snapshots build by using LASTEST dependencies. Any change will trigger a snapshot build (jekins job) and all dependent's snapshot build will be triggered too, and so if any changes break some project, that project's own build will notify the owner.
The question is about the release. The DEV build is continuous, and we want to release EVERY project against certain timestamp when it was a GREEN dev build across all projects.
How to get such release process setup?
thanks.
jenkins provides some Post-Build-Actions. You can use them to publish/archive every successfully built artifact to whereever you want.
Your Release-Job can take all the artifacts and deploy them. So you're sure all artifacts are from GREEN builds and is also independent from all the continuous jobs.
If you want to be really cool, do some smoke tests (e.g. is database connection working, external APIs working, etc) in the Release-Job as well.
best,
marco
I'm extremely new to TeamCity and need to copy files from one TeamCity agent to another. I'm basically looking for some conceptual direction so I can start researching on how to accomplish the following:
Currently have a TeamCity Agent which builds program and creates corresponding artifacts. I need to copy these artifacts to another TeamCity Agent machine.
I'm getting acquainted with the build steps, we are using a commandline build runner. So I'll need to setup the build step for copying files via commandline--any hints on how to get started is greatly appreciated.
I apologize for any conceptual or term errors. I guess this is why I'm posting this question.
Kme,
In case you want to re-use the results of one build in another (e.g., run tests using results of compilation), you should take a look at two things:
Publish your build artifacts to server (more details here)
Download an artifact from server before build starts (more details here)
This will allow TeamCity to ensure that artifacts arrive at correct agent at correct moment of time. Also TeamCity will track usages of such artifacts.
We are using bamboo as our integration server. During each build it produces binary packs of our products. Some of the built artifacts then goes in to QA.
Is there a way to retain build artifacts of a certain build job number, irrespective of the global build expire configuration. For an example, at some point we identify one of the built artifacts as release candidate.
The QA should be able to download that specific pack even after one weeks time. Right now we are copying the build artifacts from CI server to some other machine. It is a script, but still it is a manual process.
In Hudson there is an option called 'keep this build forever'.
Depending on your version this is possible by applying a label to it. Under a plan's configuration on the "Miscellaneous" tab, you can set a label which can then be used to prevent a build from expiring.
For example, our system has builds that can get labelled "SaveBuild" which then prevents their expiry.
My TeamCity's nightly build produces more than 130Mb java doc as Build Configuration artifact.
I have to share these artifact for other teams(developers), but javadoc every time has another one URL(I know that it's possible to get it like .lastFinished), and get's new place on Build Machine.
Is it possible on each build replace old artifact with new one because I don't need need previous versions? And have independent from build version URL for accessing.
You can configure TeamCity to delete artifacts after the n-th subsequent build - set this to 1, and it won't keep much for you. Look under Administration at Build History Clean-up Policy.
And the independent from build version URL should then probably be the .lastFinished one you mention.