Skip to content
This repository has been archived by the owner on Apr 9, 2024. It is now read-only.

Provide more release tags for CI consumption stability #112

Closed
msorens opened this issue Nov 18, 2020 · 3 comments
Closed

Provide more release tags for CI consumption stability #112

msorens opened this issue Nov 18, 2020 · 3 comments
Labels

Comments

@msorens
Copy link

msorens commented Nov 18, 2020

I mentioned this some time ago as a casual comment in slack, but surfacing here just to give a bit more exposure.

Since the v1 tag on semgrep-agent is continually bumped with new releases, that means that consumers of the v1 docker image are always at risk of having their CI build break due to a new release. My release engineering folks rather frown on that, which means I cannot make use of semgrep's failing a build iff there is a new problem in our code.

It would be nice to have the option to pin to an unchanging version of your docker image so I could eliminate the risk in my CI pipeline. Not saying you have to immobilize "v1" --I understand the desire to keep that at the head for your own needs--but perhaps have additional tags corresponding to the encapsulated semgrep (since I imagine that changes more frequently).

@underyx
Copy link
Member

underyx commented Nov 18, 2020

Yeah, we'll need to address this very soon! Thanks for creating an issue for the discussion. We're still shipping backwards incompatible API changes to Semgrep Community sometimes and might need to hold out for a bit longer without worrying about deprecation policies, personally I'd guess a month or so.

In the meantime you can probably specify pin the image yourself by getting the latest SHA here: https://hub.docker.com/layers/returntocorp/semgrep-agent/v1/images/sha256-fd994be1b39501685a433835a3a54a975412bb9f77707b4e359332c4458b640b?context=explore

So according to this page right now you could use this image:

returntocorp/semgrep-agent:v1@sha256:fd994be1b39501685a433835a3a54a975412bb9f77707b4e359332c4458b640b

and it would always use the same exact code. We don't advertise this option and wouldn't recommend this though cause failing due to API changes is likelier now, than due to a new semgrep-agent release.

@msorens
Copy link
Author

msorens commented Nov 19, 2020

Thanks for the details, @underyx . Based on your advice, then, I will hold off using that for now.

@brendongo
Copy link
Member

Moving forward, functionality here will be in lockstep with semgrep releases so we can include an additional tag for stability

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Development

No branches or pull requests

4 participants