Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Evolution of Blackfire support #419

Open
lolautruche opened this issue Jul 3, 2020 · 6 comments
Open

Evolution of Blackfire support #419

lolautruche opened this issue Jul 3, 2020 · 6 comments
Assignees

Comments

@lolautruche
Copy link

Hello there 👋 ,

Blackfire recently published an official buildpack, providing the agent and the CLI tool (doesn't appear on Heroku elements yet though).
It is partially inspired by your amazing work in the official buildpack for PHP, and is needed for Python and Go, which we now support officially.

It would be nice to harmonize the way developers can install and use Blackfire on Heroku, which is why I'm creating this issue.

My suggestion is to:

  • Keep PHP support the way it already is, especially when it comes to install the probe;
  • Remove the Blackfire agent and CLI from the PHP buildpack in favor of using the Blackfire buildpack, in addition to the PHP one;
  • Document what developers need to do in order to use Blackfire (adding the Blackfire buildpack in addition to the PHP one).

WDYT?
Of course, I'd be glad to contribute to thes changes 😉 .

@dzuelke
Copy link
Contributor

dzuelke commented Jul 9, 2020

Cool.

Yeah, so, having the agent (I don't think the CLI tool is installed by the buildpack, but could be wrong) as a separate package is on my todo for the next few weeks.

The goal there is/was to allow independent updates of the two.

I can then change the buildpack to detect an agent from that buildpack and provide that package for our platform installs, then the buildpack won't pull in its own package.

Otherwise, it'll continue to be installed by the PHP buildpack, so that users do not have to also install a buildpack just to use the extension.

How does that sound?

P.S. there is obviously a bit of a concern around backwards compatibility - how will we know, in a far future, that an old agent version a user is somehow using (if that's possible?) works with a newer extension version, or vice versa?

@dzuelke dzuelke self-assigned this Jul 9, 2020
@lolautruche
Copy link
Author

Hello @dzuelke

Ah, so that's a great opportunity then 😄 .
The PHP buildpack does install the CLI tool as well 😉 .

I can then change the buildpack to detect an agent from that buildpack and provide that package for our platform installs, then the buildpack won't pull in its own package.

So if the Blackfire buildpack is present, you'd activate the installation of the probe, right?
What do you mean by "provide that package for our platform install"?

Otherwise, it'll continue to be installed by the PHP buildpack, so that users do not have to also install a buildpack just to use the extension.

While I'm not a fan of having 2 different ways of installing the agent, I think it's probably the best for BC. Would it be possible to display a deprecation warning somehow?

P.S. there is obviously a bit of a concern around backwards compatibility - how will we know, in a far future, that an old agent version a user is somehow using (if that's possible?) works with a newer extension version, or vice versa?

A new version of the agent will be installed for every deploys, so that shouldn't be a problem.
As for the probe version, there is a warning displayed in profiles when an old version is used. There might be some glitches in the far future if the probe and agent versions are not compatible any more, but that will most likely go through our support channel, and it is quite easy to spot IMHO.

@dzuelke
Copy link
Contributor

dzuelke commented Jul 9, 2020

I can then change the buildpack to detect an agent from that buildpack and provide that package for our platform installs, then the buildpack won't pull in its own package.

So if the Blackfire buildpack is present, you'd activate the installation of the probe, right?
What do you mean by "provide that package for our platform install"?

No, I meant I'd check if the blackfire-agent is there (from your agent buildpack), and if so, I produce {"provide": {"heroku-sys/blackfire-agent":"1.2.3"}} in the "system" composer.json that we use for installation of PHP, extensions, and so forth (we take the app's composer.lock and generate something like {"require":{"heroku-sys/php":"~7.3.0"}} from it, and run that against a custom repository with a custom installer that then installs the PHP runtime using Composer).

I hadn't considered auto-installing the extension in case the buildpack is there... it currently already gets auto-installed if BLACKFIRE_LICENSE_KEY is set, so that wouldn't change, I guess.

While I'm not a fan of having 2 different ways of installing the agent, I think it's probably the best for BC. Would it be possible to display a deprecation warning somehow?

Yeah, no problem.

@lolautruche
Copy link
Author

Alright then :-)

@tristanbes
Copy link

tristanbes commented Jun 17, 2021

Hey 👋

We've noticed Heroku runs an outdated version of Blackfire as reported by the latter:

We noticed that you are using an outdated agent version for the “Production UK” environment.
The v1 is deprecated and will sunset on Sept, 1st 2021. Consider upgrading to v2 soon.
Read more at https://blackfire.io/docs/up-and-running/agent-upgrade

Is this issue involves this ?

@dzuelke
Copy link
Contributor

dzuelke commented Jun 25, 2021

#488 addresses most of what we discussed.

It now only installs the agent if the user doesn't have the blackfire buildpack set on their app.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants