Checkout in different workflow jobs, same SHA?

Build Environment
1

I have a simple workflow that has a build job, a hold (type approval), then a release job.

If I perform a checkout in the build job and the release job, will they always use the same SHA and get the same code?

Context:

I have a Clojure library I want to release to Clojars. I don’t want every commit to automatically get deployed so that is why I added the manual approval step.

I build a jar in the build job and store it as an artefact, as its nice to be able to manually download a CI built jar if required.

Originally I also persisted the jar to the workspace which I restored in the release step. I then tried to use lein deploy to push this prebuilt jar to Clojars. However lein rebuilds the jar which meant it contained no source files and was completely broken!

So my options seem to be:

  1. try and stop lein from rebuilding the jar
  2. persist the src to the workspace
  3. checkout the same SHA again

If checking out code in different workflow jobs is smart enough to use the same SHA that seemed like the simplest option, but was unable to find a definitive answer, hence my question!

2

I imagine it would use the same hash, though I’ve not done this, so I cannot say definitively.

However, if it does not, then the hash should be available in env vars at the start of the held job.

I think the simplest approach is to build the workflow as you want it to work, and then try it (get the job into a hold state, push a dummy commit to your deployment branch, then release the hold, and see what happens).

If both of the above approaches fail, then you can always use a workspace to copy over the required hash.

3

Hi @halfer, thanks for the reply, I just tested this as per your suggestion.

I can confirm the CIRCLE_SHA1 was set to the correct SHA of the commit that triggered the workflow and the built in checkout step does:

git reset --hard "$CIRCLE_SHA1"

So unless I’m misunderstanding reset --hard :thinking: I’d say it’s safe to checkout in multiple jobs in the same workflow, regardless of how long they are on hold or how many additional commits have been made.

1 Like
4

Great stuff. :+1:

Did you find that a standard checkout step was insufficient for your needs (perhaps because it would checkout the wrong hash?). I think git reset --hard would be fine too, but it is worth using the tools available if they will work.

5

The git reset --hard is part of the standard checkout step, I didn’t need to modify or add any custom git commands.

You can see what the standard checkout step is actually doing by expanding it in the UI, as mentioned in this article https://support.circleci.com/hc/en-us/articles/115015659247-How-do-I-modify-the-checkout-step-

6

Ah, beg your pardon, I thought you’d use git reset instead of checkout. I should read more carefully :sleeping: :grinning:

7

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.