Is there a plan to add a “rebuild” button for a job that will not trigger the whole workflow? I know I can rebuild with SSH, but it would be really great to have something that didn’t do that. I especially want to be able to do this for successful builds. My use case is redeploying my application without waiting around for tests that already passed on the initial deploy.
I think this has been discussed before, and there was a sense in that discussion that it would not be trivial to do. For example, if you used a workspace in your job, and expected files to be in a specific state, should the snapshot of those files be replayed to your re-running job even though an earlier job has not set them up in this case? Or should the workspace be empty?
I take the view that rebuilds are meant to be thought of as re-running a job in their old state, rather in the new one, so I wonder if a rebuild is not what you want anyway. I think it would be better to find a way to trigger the job in a fresh build.
Could you add a tag trigger to that job, so that it runs separately (outside of the workflow) if a specific tag push is received?
Thanks for the reply. I found some old threads, but none of them talked about the workspace issue. I don’t need the workspace in this case, so I didn’t consider that. It seems like this could be addressed by not allowing job rebuilds if the job uses the
The tag solution is a clever one, but will not satisfy my needs. The goal is to be able to trigger redeploys of my application from a mobile phone.
Hi Nathan. Can I ask the situation where you need to redeploy with no changes? That will help us better determine if there is a workaround, or a need for a feature request.
The situation is a hypothetical one where our servers need to be restarted but no developer has access to their machine. Since our deploys trigger restarts, we can then trigger a redeploy/restart using only a mobile phone.
Let me know if more details would be helpful.
Thanks for explaining. I’m not sure how this would work under the covers (skipping tests) and still have your code be on the box to be deployed.
I took a look and didn’t see any matching feature requests that I think would solve your use case, can I ask you to create a new one here https://ideas.circleci.com/ideas so our product team can take a look?
edit: I’m imaging something like https://ideas.circleci.com/ideas/CCI-I-201 with a check that “if rebuild type Y don’t run tests” but I expect our product team can come up with better
Our deployment happens in its own job, and it runs the
checkout command as its first step.
In case it’s helpful, here’s the
workflows section of our
workflows: version: 2 build-test: jobs: - yarn-test - compile - rake-test: requires: - compile - hold: type: approval requires: - rake-test - yarn-test filters: branches: only: /^master$/ - notify-approval: requires: - rake-test - yarn-test filters: branches: only: /^master$/ - deploy: requires: - hold filters: branches: only: /^master$/
Would creating a separate workflow that doesn’t normally run, has only one job and then kicking it off with a button wired up to the API endpoint https://circleci.com/docs/api/#trigger-a-new-build-by-project-preview work?
IIRC, the API ignores the filters, so I think you could filter the second workflow to never run, then launch it via a API call/mini UI on your side.
Not saying I don’t like the idea, I’m brainstorming faster ways to make it happen since I know our teams have a lot on their plate.