Help

The Community will be temporarily unavailable starting on Friday February 28. We’ll be back as soon as we can! To learn more, check out our Announcements blog post.

Releasing to additional remotes

Topic Labels: Custom Extensions
Solved
Jump to Solution
3110 3
cancel
Showing results for 
Search instead for 
Did you mean: 

I’m trying to use the --remote feature of the CLI to install my Custom Block into another base, but it doesn’t seem to be working. I’m not sure if I’m doing something incorrectly.

I went through the process of “Install a block”, “Build a custom block”, and saved the appID/blkID, leaving an empty and uninitialized block

CleanShot 2020-09-09 at 17.06.41@2x

Then I ran the CLI commands, with apparently successful results:
Carbonize 2020-09-09 at 5.09.08 PM

But my block remains uninitialized. I’ve tried refreshing multiple times, and I’ve tried running the CLI commands again, and it doesn’t look like it’s done anything.

I tried running just $ block release as well (not specifying a --remote), and my default installation of the block was updated (tooltip indicates “last updated” with today’s date). So it appears it is only the remote option that is not working as I expected.

@Kasra
@Michelle_Valentine

1 Solution

Accepted Solutions
Emma_Yeap
Airtable Employee
Airtable Employee

@Jeremy_Oglesby double checking, are the asterisks in the app***/blk*** screenshot added by you? (The actual block list-remotes command should not redact the ids).

To help debug, could you please check/share these things:

  • Version of the CLI you are using
  • On your custom block installation in the new base, click the name, “Edit block”, “How do I run blocks locally”, “Continue”, and check the app.../blk... shown in step 2 matches the content of .block/agenda_base_test.remote.json
  • Check whether block run --remote agenda_base_test works and allows you to run the block in that installation
  • Check the other block dashboards in your new base to double check the remote corresponds to the installation you are looking at (vs updating a different block in your base)

See Solution in Thread

3 Replies 3
Emma_Yeap
Airtable Employee
Airtable Employee

@Jeremy_Oglesby double checking, are the asterisks in the app***/blk*** screenshot added by you? (The actual block list-remotes command should not redact the ids).

To help debug, could you please check/share these things:

  • Version of the CLI you are using
  • On your custom block installation in the new base, click the name, “Edit block”, “How do I run blocks locally”, “Continue”, and check the app.../blk... shown in step 2 matches the content of .block/agenda_base_test.remote.json
  • Check whether block run --remote agenda_base_test works and allows you to run the block in that installation
  • Check the other block dashboards in your new base to double check the remote corresponds to the installation you are looking at (vs updating a different block in your base)

Thank you so much for the quick response, @Emma_Yeap.

Yes, I redacted the ID’s myself for the screenshot - they list fully when I run $ block list-remotes.

And it turns out I had the wrong appID/blkID… Thank you for that instruction on how to retrieve them.

Using the correct appID/blkID worked.

And now I’m left scratching my head as to where I got the incorrect appID/blkID from… I only installed and copied the ID of one block, that I can remember :confounded: . I must be getting old…

No problem, glad it’s working now!