If a build is running and you go to the dashboard and abort it, does the publishers section still run?
yep it is still ran
That's the idea of publishers, to publish the result of a build :-)
build ok, build broken or build aborted.
Related
When I used vue-cli-service to build my project, the console prompted:
DONE Build complete. The dist directory is ready to be deployed.
INFO Check out deployment instructions at https://cli.vuejs.org/guide/deployment.html
The command I use is:
vue-cli-service build
However, the process will not automatically shut down.
Usually, I don't have to worry about this, but when I use tools like jenkins, the build process is not closed and the jenkins can't continue.
I already know the reason, because I also executed a piece of code to monitor file changes when I packaged, which made it impossible for the process to exit after packing.
I have my .gitlab-ci.yml file set up in the typical three stages: test, build, deploy. During the build stage, I run a command that compiles my project and puts it in a tarball. The build stage appears to execute successfully because it moves on to the deploy stage, but the deploy stage then says it can't find the tarball. Is it in another directory? What happened to it? Thanks.
For each test gitlab-ci clean the build folder, therefore the output files of the build stage are not available in the deploy stage.
You need to rebuild your project also in the deploy stage.
The "stages" are only useful to order your tests, i.e. avoid to try to do a deploy test if a build test failed.
EDIT:
Since Gitlab 8.6, it is possible using dependencies feature
I was surprised to see the same behaviour (on GitLab 8.4).
I use cmake to create makefiles, then make to build, and then make test to run the test. I run all these in a build/ directory.
I don't want to repeat myself and identify easily which steps are failing. As such, I've created different gitlab-ci stages: cmake, make, test, etc. I then tell gitlab-ci to keep the build directory using the cache option:
cache:
key: "$CI_BUILD_REF_NAME"
untracked: true
paths:
- build/
I think that the key option will keep the same build directory for all stages acting on the same branch. See the gitlab-ci doc here: http://doc.gitlab.com/ce/ci/yaml/README.html#cache
EDIT: Don't use the cache for this! GitLab implemented reusable artifacts between stages in 8.4: https://gitlab.com/gitlab-org/gitlab-ce/issues/3423
The CI runners will have to be adapted to support this. See: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/336
In my gradle project I have a task Task1 with many dependency tasks Task1Dep1, Task1Dep2, Task1Dep3... Task1DepN.
Is there a way to split my execution of Task1 such that Task1Dep1, Task1Dep2 in one execution and then run Task1Dep3 ... Task2DepN in a second execution.
The reason I want to do this is that if this is possible then it will be a solution to a problem I posted about here: How to read latest property in property file that is updated earlier in gradle execution.
I was able to solve this issue as follows.
The gradle task I wanted to run was the release task for running the Townsfolk gradle-release plugin.
Normally this would be done as:
./gradlew release
Due to various issue sI ran into with the svn support in this plugin and using it with Android I had to split the underlying sub-tasks for this plugin as follows:
./gradlew -PusesSnapshot=true -PversionModified=true initScmPlugin checkCommitNeeded checkUpdateNeeded unSnapshotVersion
./gradlew -PusesSnapshot=true -PversionModified=true initScmPlugin confirmReleaseVersion checkSnapshotDependencies build preTagCommit
svn update
./gradlew -PusesSnapshot=true -PversionModified=true initScmPlugin createReleaseTag updateVersion commitNewVersion
I found the underlying tasks using:
./gradlew tasks --all
My application is based on node.js, and uses bower.js and others task runners to compile assets and build the actual assets (minify, concat, inject...).
Since this is my first application that will be running in a scalable enviroment on Heroku, I was wondering how is the process of deploying.
I mean, my current workflow is:
cd myRepo
git commit [blabla...]
git push heroku
And when running it, it runs npm run wich calls geddy and runs the server.
If I build before pushing, there will be files that are kind of redundant, but if I push the unbuilt project, it should build it on the cloud. Is that the main idea?
Thanks
it should build it on the cloud. Is that the main idea?
Correct; checkout the Dev Center for more Nodejs information:
Heroku Dev Center: Getting Started with Nodejs
Specifically here, it lists information on bower:
Heroku Node.js Support: Customizing the Build Process
I have 2 tasks in my CruiseControl settings that work on the same build:
Build MyProg
Rebuild MyProg
It's a C++ thing, occaisionally a rebuild (clean and build) is needed to clean up linking errors.
I would like the 2 tasks to share the same status (Failed/Succeeded). That way I'm not forced to re-run the Rebuild task just because it failed last time if I want to get everything back to "Green".
Anyone know how it can be done?
After a bit of thought, I think I am going about this ass-backwards.
The "Rebuild" task could be replaced with a very minimal "Clean" task which should pass whether the build is broken or not. The "Build" task would then automatically trigger following the "Clean", updating the official build result.