Hi there, the Capistrano will only send deploy markers (and that feature is deprecated in for of the revision config option).

You can send markers using an HTTP request, as documented on this page.
Hope that helps!

@tombruijn I know I can use HTTP API, but this is very inconvenient. It requires setting up a personal access token, and using an HTTP client - all while Appsignal is already active in Capistrano context, has the push API key present, and could be easily modified for the purpose of submitting a custom (non-deployment) marker. All that's needed is simple: allow the general push API key to submit custom markers (not just deploy markers), and expose a method to add a custom marker via Appsignal module.

The personal access token part is pretty bad in particular. A PAT gives access to ALL my projects across ALL organizations. It's not safe to share like a push API key is.

Hi there, the Capistrano will only send deploy markers (and that feature is deprecated in for of the revision config option).

Why is it deprecated? I do use revision for precise tracking of which code causes problems (as we may have multiple versions running at the same time) - but a deployment marker is an extremely useful thing that we augment with extra debug data (in user field) to give more context about that deployment (e.g. who performed it, from what computer, etc).

@tombruijn I know I can use HTTP API, but this is very inconvenient. It requires setting up a personal access token, and using an HTTP client - all while Appsignal is already active in Capistrano context, has the push API key present, and could be easily modified for the purpose of submitting a custom (non-deployment) marker. All that's needed is simple: allow the general push API key to submit custom markers (not just deploy markers), and expose a method to add a custom marker via Appsignal module.

The Push API's markers endpoint (the one used by the Capistrano integration) is not one we want to modify to support reporting custom markers. As mentioned before, it's a deprecated endpoint that we'd like to remove, because that way of reporting deploys is inaccurate, more details below.
Although reporting custom markers through the Push API should be possible, we would prefer to report it another way. See my next answer.

The personal access token part is pretty bad in particular. A PAT gives access to ALL my projects across ALL organizations. It's not safe to share like a push API key is.

Fair point about using a PAT. We're considering adding an endpoint for on the public endpoint API to report custom markers. On that API, authentication works with a Push API key + app and environment, or Front-end API key.

I think that would resolve the issue with the PAT permissions.

Hi there, the Capistrano will only send deploy markers (and that feature is deprecated in for of the revision config option).

Why is it deprecated? I do use revision for precise tracking of which code causes problems (as we may have multiple versions running at the same time) - but a deployment marker is an extremely useful thing that we augment with extra debug data (in user field) to give more context about that deployment (e.g. who performed it, from what computer, etc).

For context: Deploy markers created through that Push API's markers endpoint are a leftover from a very long time ago. It's been internally deprecated for a long time and we removed functionality like the appsignal notify_of_deploy CLI command many version ago. It's only in the Capistrano integration and others because some customers still rely on it, but we'd like to remove it.

The moment a deploy gets reported via a deploy marker via the HTTP endpoint, and when a new deploy actually starts reporting data, is not the same. We have issues where data from new and old deploys gets asssigned to the wrong deploy due to this timing issue.
Using the revision config option we tag the incoming trace data with the revision and we'll always assign it to the correct deploy. We don't have to assign trace data a deploy after the fact.

The deploy marker reporting via Push API's markers endpoint also makes reporting data from applications simultaneously running multiple revisions of their application difficult. If data from an older deploy is coming in after a new deploy marker is created via the Push API markers endpoint, it will get wrongly assigned to the new deploy. No such problem with the revision config option.

You say you're already using the revision config option, great! It's not meant to work together with deploy markers reported manually, so I'm curious to know if you run into any problems with that.
If you want to track when the deploy process was started or completed on a production server, it's still possible to report this with a custom marker. I would recommend using a custom marker, but I see your concerns with using the PAT to authenticate.

With the Public endpoint solution I described above I think we can include a wrapper around our HTTP transmitter in the Ruby gem to send a custom marker so you don't need to do this yourself. I imagine something like:

Appsignal::CustomMarker.report(
  :message => "Deploy abcdef123 completed by Damian from PersonalLaptop",
  :icon => "🚢",
  :created_at => Time.now.utc.iso8601
)

I can't provide an ETA on when we'll at that endpoint.

Hi @Nowaker, we've just published Ruby gem 4.5.0 with a new helper to create custom markers via the public endpoint API (added in #1378) which I described in my previous comment.
This means you can now create custom markers without needing to use a PAT.
Let us know if you run into any problems or have any further questions :)

Nice. Thanks. :)

You say you're already using the revision config option, great! It's not meant to work together with deploy markers reported manually, so I'm curious to know if you run into any problems with that.

Yeah, using both. No issues. What would the issues be, really? Appsignal correctly recognizes the revision of code running in a given process. ...Or so I think?

You say you're already using the revision config option, great! It's not meant to work together with deploy markers reported manually, so I'm curious to know if you run into any problems with that.

Yeah, using both. No issues. What would the issues be, really? Appsignal correctly recognizes the revision of code running in a given process. ...Or so I think?

I expect no problems, but I honestly never tried that before. It only applies the deploy marker from the HTTP request if the trace has no revision already. Ignore I brought it up 😅