Rebuild Job without SSH

Deployments
1

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.

2

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?

1 Like
3

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 attach_workspace command.

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.

4

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.

5

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.

1 Like
6

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. :thinking:

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 :slight_smile:

7

Our deployment happens in its own job, and it runs the checkout command as its first step.

8

In case it’s helpful, here’s the workflows section of our .circleci/config.yml

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$/
9

Oh. Hmm.

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. :thinking:

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.