Golang as a dependency

Development Step Dev
1

Some steps have golang declared explicitly as a dependency e.g. https://github.com/bitrise-io/bitrise-steplib/blob/d3581bdf1de00ddbbe0f0c7113f75d855312e8b1/steps/recreate-user-schemes/1.0.0/step.yml#L23
while other ones don’t have it e.g. https://github.com/bitrise-io/bitrise-steplib/blob/master/steps/activate-ssh-key/4.0.3/step.yml despite that they use go toolkit.

My understanding is that Bitrise supports go toolkit on all the stacks so go is guaranteed to be preinstalled like bash (which is never declared as explicit dependency). So declaring go as a dependency is redundant and only increases step runtime by apt-get or brew invocation (if there are no other dependencies it can be completely skipped).

Is it correct or maybe there is some reason why go is still declared as a dependency?

1 Like
2

You are right, these days defining Go as the toolkit for the step should be enough.

In the past, before we introduced the built in Go toolkit handling, the steps used the “standard” procedure that’s available for any language (meaning: the step’s entry point by default is step.sh if no toolkit is defined, but from step.sh you can run another script right away, e.g. a Go or Ruby one. For those you had to define go as a dependency).

There are steps which support both, which was important in the transition period, before we declared the Go toolit as stable in the CLI, as well as so that the step still works with older CLI version which don’t have the Go toolkit support.

Today that shouldn’t be a concern as we had another breaking change in the official steplib and so only newer CLI versions are supported, which all have Go toolkit support.

So, if you see a step that specifies the Go toolkit but also lists go as a dependency feel free to send a PR to remove the dependency declaration from it :slight_smile:

1 Like
3

Thanks, will do that :slight_smile:

4

Using this simple snippet run inside directory containing current StepLib: grep -r "name: go" * |cut -d "/" -f 2 |sort -u it seems that there are 64 steps potentially declaring go as a dependency.
Some of them like slack seem to contain more leftovers like step.sh file.

I’ve just send few PRs.

5

I’ve found another inconsistent dependency.
git-clone step invokes git as shell command but it does not declare git as dependency. However, for example heroku-deploy step declares such dependency.

Can git be treated as available on all the stacks so it should not be a dependency?

6

Hi @koral,

I created an item in our backlog for consolidating dependencies.

7

Cool, thanks.

Does it mean that git dependency is also redundant and should be removed?

8

I think it is.

9

Now I can answer my own question :slight_smile:

Only toolkits themselves (in practice only go at the time of writing this) should not be declared as dependencies. Everything else should be listed. Detailed info can be found in docs:

1 Like
10

@koral git is indeed a special one, but not because it’s preinstalled on our stacks. The reason is that the Bitrise CLI itself requires git to fetch steplib/step related data. Theoretically the CLI can work without git but in practice that limits its usability quite a bit, and so git is marked as a dependency of the CLI itself.

That said I’m not sure if the CLI itself actually checks whether git is available or not, mostly because git isn’t used by the CLI but by stepman :thinking:

11

OK, thanks for the explanation.

In theory one can use only steps with path:: source so there is nothing to fetch by git in such case.

Additionally (not sure about this, haven’t checked that in sources if it will work in such way) if everything (steplib and steps) are already downloaded then git should not be needed as well.

1 Like
12

Correct.

The steplib itself requires git - if there’s at least one step with a version that’s not available in local cache or just a step with “always latest” version config then the CLI will do a steplib update when the build is started.

So technically possible to not to require git for a bitrise run, but in practice not really.