I am running my wedriverio(selenium wrapper in javascript) tests on Jenkins
After each build the jenkins creates and attaches artifacts which is taking very long time (the test cases complete in 2 minutes, but the artifact steps take about 1 hr).
I also noticed that artifact is allure-report.zip
Is there any significance of this artifact if I already have console logs and allure-reports generated?
How to not generate and attach artifact after each build?
Jenkins has no control over the artifacts being created after starting a build via the execute shell command. The build itself is what creates artifacts. Parts of the build process that can also create artifacts are post-build actions such running tests or plugins.
I suggest you familiarize yourself with your Jenkins job to locate what creates the allure_report.zip file.
With Jenkins you can control which artifacts you want to preserve and make available easily on the UI via the Archive the artifacts in Post-build Actions. This does not create the artifacts. It simply tags and archives them as something special to be available outside of the workspace. If this is the step you think is slow (attaching the generated allure_report.zip file), you can remove it from the list of files to archive.
I would like to share byproducts of one jenkins job, with another one that run after.
I am aware that I can set "use custom workspace", but that would merge the jobs together; which is not what I want. I just need to move few files in a location, that are read by the next job.
So far I can't find out how you actually tell Jenkins jobs to look for a specific folder; since it does not have a concept of file system, beyond what is going on in the job workspace folder.
Is there a way to access the host file system, or declare a shared folder inside jenkins (like in the main workspace folder, which contains all the other jobs?), so I can copy and read files in it, from different jobs?
Where possible I would like to avoid plugins and extras; I would like to use what is included with Jenkins base.
I realize you want to avoid plugins, but the Jenkins-y way to accomplish this is to use the Copy Artifacts plugin, which does exactly what you want.
There are a variety of problems that you may run into when trying to manage the filesystem yourself. (How do you publish to a common location when running on different build nodes? How do you handle unsuccessful builds?) This solution uses Jenkins to track builds and artifacts. In the absence of a separate artifact repository, its a lot better than trying to manage it yourself.
To use Copy Artifacts:
As a Post-Build step, choose "Archive Artifacts" in the first job and enter the path(s) to the generated files.
Then in the second job, add a "Copy Artifacts from another project" build step to grab some or all files marked as artifacts in your first job. (By default, Jenkins will re-create the paths of the generated files in the second job's workspace, which may or may not be what you want, but you can change this behavior.)
Configure the Jenkins to run a Maven build, and deploy your artifacts with "mvn clean deploy" This will push it to an "artifact server" which you probably have, or if not, need to add / configure.
Then in your downstream job, also a Maven job, you configure it to depend on the same artifact that was published in the upstream job. This will trigger a download of the artifact from the artifact server and make it available to the build.
Might sound like a very basic question - but I am unable to find any article which explains why Jenkins provides a post build step as well as action.
In Jenkins - I do see that the options are different in post build step vs. action, but
what is the order of execution?
When should we use which option?
What are the best practices?
At a glance, here is Jenkins' job workflow (without additional plugins)
[On demand, if needed] Install tools, (such as JDK, Ant, Maven, etc).
[Optional] Perform SCM checkout, (such as SVN or Git).
Perform build step(s), (such as build Ant project, compile code, etc).
[Optional] Perform post-build steps(s), (such as Archive Artifacts, send email, etc).
There are plugins that allow to perform actions right after Tools installation, such as Pre-SCM-step and EnvInject plugins. There are also plugins that add a lot more possible Build Steps and Post-build steps.
The difference between Build and Post-build steps is based partially on logical separation, partially on workflow configuration.
From the logical perspective, when you build/compile a project, that's a "Build" step, whereas when you Archive Artifacts, since that happens after the build, that's a "Post-build" step.
But there is also workflow configuration considerations, and it has everything to do with:
"When do the the builds fail", and with
"Build Status" (such as Success, Unstable, Failed)
When there are multiple "Build" steps, Jenkins:
Executes the first build step
Checks for exit code of the first build step
If exit code is 0 (success), Jenkins continues to next build step (if there is one)
If exit code is not 0 (failure), Jenkins marks build as FAILED, and continues to Post-build actions.
Jenkins executes Post-build steps (regardless if build was marked FAILED or not)
So, in other words:
If Build step succeeds, Jenkins can execute the following Build steps (if any).
If Build step fails, Jenkins will not execute the following Build steps.
If all Build steps succeeded, Jenkins will mark build SUCCESS.
If any Build step failed, Jenkins will mark build FAILED.
Post-build steps are executed regardless of Build Status (FAILED or not).
Technically, all post-build steps should be executed at all times, however in practice, if a Post-build step exceptions, the job never completes which can lead to some Post-build steps not being executed.
Also, generally Post-build steps do not change the Build Status, but there are some that are specifically designed to do that (for example, when Archiving Artifacts, you can choose to mark build FAILED if not all artifacts are found, even if after all Build steps, the build was marked SUCCESS)
So, knowing the above, it's your responsibility to design your job, and decide what steps need to be executed one after another, only if previous was successful, and will affect the Build Status (i.e. Build steps), and what steps need to happen at all times regardless of result (i.e Post-build steps).
EDIT:
Since I keep getting comments, here is a screenshot of a brand new clean installation of Jenkins (Windows) ver.1.634 (as was mentioned in comments).
On the screenshot, note the following:
New Freestyle project.
Scrollbar all the way down, there is nothing more on page.
Version 1.634 (as requested).
Build section with Add build step drop down.
Post-build Actions section with Add post-build action drop down.
So, to re-iterate my previous comment:
There is only one post-build "anything"
whether you want to call it "step" or "action" (Jenkins changed the labeling over the years).
Custom plugins can add a lot of extras, but for a clean install a basic job is just as I have described.
For an item (job) created as a Maven project build steps are not configurable (only the maven goals are configurable for the build), so two new extra categories are available to configure: pre-build step and post-build step.
In my experience pre/post-build step are used to execute actions that can influence the build result (such as Sonar Analysis), and post-build actions for actions to be performed based on the build's result (such as e-mail notifications).
Clarification. Post build Step can be set to only execute when build has a specific status. i.e. if failed do something (send logs to someone?) if passed or unstable do something. i.e. tag the source so that it can be promoted for release?
Post build action is ALWAYS executed. There is where you send emails, archive artifacts, send artifacts to master (if using slaves and have the plugin), etc.
I use the Post build Step to tag/label the successfully built source code in my GIT workspace. I use a small script to do that.
Now I just wish that Post Build step was available in Freestyle jobs since it is such a great option for only tagging successful builds.
We have a build project which always generates three files (artifacts). When promoted, these files will be used for a setup package. With the promoted builds plugin, it's only possible to promote all artifacts of a build. Is there a way to only promote selected files of a build? Currently I can only think of splitting up the build process into separate projects - but then we've the problem with different workspaces.
Thanks a lot.
The Promoted Builds plugin by itself does not "promote" the artifacts. It promotes a build run.
Part of the promotion process may be a Copy Artifacts step, and that is the step that takes the artifacts from promoted build run and does ... whatever you have configured for the promotion.
In the Copy Artifacts step, you can definitely specify a pattern for the files to copy.
Here is what i am trying to achieve:
We have a SVN repository, but we dont want to promote all the changes we get via svn update!
I want to manually select each artifact and then build it via Jenkins and deploy it.
Any plugin which will allow me to do that? I dont have a simple criteria like exclude *.jar or *.xml but it is purely manual human intervention.
Thanks,
Zoom
What about making a new job with build parameters. One of the parameters could be a svn tag/branch to build/run/use, then have a build step that runs a script. In the script you can do whatever you wish with that svn tag, including a checkout and build.
Or, if you want to use pre-built artifacts from another job, you can specify links to those artifacts in the build parameters or a job name/number and have the script automatically grab them for you.
Many different ways to run a job manually :)